I'm trying to benchmark my application using perf. The application is c++ based and I want to evaluate
L1-dcache-loads,L1-dcache-load-misses,L1-dcache-stores,cycles,instructions,cache-references,cache-misses,bus-cycles,branch-misses
I want to avoid seeing perf events in my output to make it more easily readable. Trying to run following command to capture the output:
perf record -g -e "L1-dcache-loads,L1-dcache-load-misses,L1-dcache-stores,cycles,instructions,cache-references,cache-misses,bus-cycles,branch-misses" --exclude-perf Binary-name
but above mentioned command is failing with following error:
--exclude-perf option should follow a -e tracepoint option
Usage: perf record [options] [command]
or: perf record [options] -- command [options]
--exclude-perf don't record events from perf itself
If I don't use --exclude-perf option then my command runs just fine without any error.
Let me know what mistake I'm making while adding the option --exclude-perf
--exclude-perf is not for sampling/profiling events like you used (Hardware CPU counters). Is it only for tracepoint events:
http://lxr.free-electrons.com/source/tools/perf/Documentation/perf-record.txt
151 --exclude-perf::
152 Don't record events issued by perf itself. This option should follow
153 a event selector (-e) which selects tracepoint event(s). It adds a
154 filter expression 'common_pid != $PERFPID' to filters. If other
155 '--filter' exists, the new filter expression will be combined with
156 them by '&&'.
It uses filters and filters are to be attached to tracepoint events.
Related
I am currently trying to restore an old arcade machine, and I'm running into issues with interpreting the events from the usb controller. In particular, the controller is sending the event code 1:300 (EV_KEY:300), but unfortunately 300 is not a valid event code. Because of this, I am unable to get it to work with the arcade software that I am using.
What I'm looking to do is run a process that intercepts the 1:300 events and turns them into some other type of event. For example, every time I press the joystick, I may want it to be interpreted as 1:194 (EV_KEY:KEY_F24).
Any idea how to do this?
Output from evtest:
Event: time 1669313468.400824, type 4 (EV_MSC), code 4 (MSC_SCAN), value 9000d
Event: time 1669313468.400824, type 1 (EV_KEY), code 300 (?), value 0
I've tried various input mapping softwares such as evsieve, but to no avail.
Output from evsieve:
While parsing the arguments "--map key:300 key:up":
While parsing the key "key:300":
Invalid argument: unknown event code "300".
Well I think I at least found a temporary workaround:
CONTROLLER1_LOCATION=/dev/input/by-id/usb-GGG_GPWiz49-event-joystick
CONTROLLER1_EVENT_PORT=event6
BTN=BTN_TRIGGER_HAPPY4
sudo /bin/evtest $CONTROLLER1_LOCATION EV_KEY 300 \
| grep "300.*value" --line-buffered \
| grep --line-buffered -o "[01]$" \
| while read x ; do sudo evemu-event /dev/input/$CONTROLLER1_EVENT_PORT --type EV_KEY --code $BTN --value $x ; done
Basically this:
Monitors the device for matching erroneous events
Takes the output that corresponds to actual button presses
And sends a virtual event from the controller
This could definitely be cleaned up, but it'll do for now
I am attempting to track deleted files with perf. I know eBPF / SystemTap is better suited here, but I am limited on the platform with tool choices (ARM).
This is how I am recording it
perf record -e 'syscalls:sys_enter_unlinkat'
For reporting
perf script -F +pid,+tid,-cpu
rm 15746/15746 7942.646974: syscalls:sys_enter_unlinkat: dfd: 0xffffff9c, pathname: 0x55a7960e6490, flag: 0x00000000
rm 15748/15748 7944.626120: syscalls:sys_enter_unlinkat: dfd: 0xffffff9c, pathname: 0x55dea122f490, flag: 0x00000000
rm 15750/15750 7947.111921: syscalls:sys_enter_unlinkat: dfd: 0xffffff9c, pathname: 0x55a515165490, flag: 0x00000000
How do I get string version of pathname as similar to that of strace output.
I also need uid of the process that deleted the file.
It will not be possible to obtain the string version of pathname using perf tools in this case.
When a userspace utility calls perf_even_open syscall with a request to monitor tracepoint events, such as the one you are trying to monitor with syscalls:sys_enter_unlinkat, a 'perf probe' function is attached to the tracepoint. You can see the probe function here.
The probe function allocates a perf buffer and validates the allocated buffer after which it invokes a bpf program.
This bpf program needs to know the 'format' of the static tracepoint event, since it needs to understand what is the structure of the binary trace output in the perf ring buffer.
The format of the event is defined in the /sys/kernel/debug/tracing/events/syscalls/sys_enter_unlinkat/format file, for your case.
If you look at this file, you will see that perf script reports the output as per the print fmt entry in the field.
name: sys_enter_unlinkat
ID: 722
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:int __syscall_nr; offset:8; size:4; signed:1;
field:int dfd; offset:16; size:8; signed:0;
field:const char * pathname; offset:24; size:8; signed:0;
field:int flag; offset:32; size:8; signed:0;
print fmt: "dfd: 0x%08lx, pathname: 0x%08lx, flag: 0x%08lx", ((unsigned long)(REC->dfd)), ((unsigned long)(REC->pathname)), ((unsigned long)(REC->flag))
The perf userspace utility will always adhere to this format and will not deviate from it. You can see some details from this commit.
Without a really extensive modification to the kernel tracepoint API, I do not see a way to achieve what you want using perf.
If all you are looking for is to track file deletion activity and you want to get additional details about it, I would suggest you try and take a look at fanotify.
I'm trying to create a process with its own namespace and then make a uid (and possibly gid) mapping. I'm following this question with this answer, but, as indicated in this recent comment, it no longer works.
Here's the skinny. First, you create a process in a new namespace with unshare:
unshare -U bash
And obtain the process it runs, with echo $$ or somesuch. You grab that PID and then, from another shell, you go:
newuidmap 12394 0 0 1
The answer, as indicated in the comment above, is:
newuidmap: uid range [0-1) -> [0-1) not allowed
In an update to the answer, Arks mentions:
it is something with settings in /etc/subuid and /etc/subguid files
I can't figure out, however, what they mean. Any idea?
Still don't understand why newuidmap does not work. But this article shows that writing to /proc/$$/uid_map does
echo '5 1000 1' > /proc/14671/uid_map
This is an one-time operation that can't be repeated, and in a single command, establishes the mapping for UIDs and GIDs.
I follow this document and using perf record with --intr-regs=ax,bx,r15, trying to log additional CPU register information with PEBS record.
But how do I view those info from perf.data? The original command is perf report, and it only shows a few fields such as overhead, command, shared object and symbol.
Is there any way to show CPU regs' value?
Try perf script data dumping command with the iregs field: perf script -F ip,sym,iregs. All fields -F are documented with source code of tools/perf/builtin-script.c - struct output_option .. all_output_options, and iregs is still here (also OPT_CALLBACK('F', "fields" ... in same file). There is also perf-script.txt documentation - https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-script.txt#L115
-F::
--fields::
Comma separated list of fields to print. Options are:
comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
srcline, period, iregs, brstack, brstacksym, flags, bpf-output, brstackinsn,
callindent, insn, insnlen. Field list can be prepended with the type, trace, sw or hw,
to indicate to which event type the field list applies.
There were commits into linux kernel git which mention flag --intr-regs. Start from option implementation:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=intr-regs&type=
tools/perf/builtin-record.c
OPT_CALLBACK_OPTARG('I', "intr-regs", &record.opts.sample_intr_regs, NULL, "any register",
Then search for 'sample_intr_regs' in commits: https://github.com/torvalds/linux/search?q=sample_intr_regs&type=Commits
Several commits were about kernel part and perf_attr debug print. But this has example of intr-regs printing (Sep 1, 2015)
https://github.com/torvalds/linux/commit/532026612455a4a6fd27c1b2e7111263f63218a2
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
- Add ability to specify to select which registers to record,
to reduce the size of perf.data files, and also allow printing
the registers in 'perf script': (Stephane Eranian)
# perf record --intr-regs=AX,SP usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.016 MB perf.data (8 samples) ]
# perf script -F ip,sym,iregs | tail -5
ffffffff8105f42a native_write_msr_safe AX:0xf SP:0xffff8802629c3c00
ffffffff8105f42a native_write_msr_safe AX:0xf SP:0xffff8802629c3c00
ffffffff81761ac0 _raw_spin_lock AX:0xffff8801bfcf8020 SP:0xffff8802629c3ce8
ffffffff81202bf8 __vma_adjust_trans_huge AX:0x7ffc75200000 SP:0xffff8802629c3b30
ffffffff8122b089 dput AX:0x101 SP:0xffff8802629c3c78
#
I find a way to achieve it by using perf report -D, and then find the registers' name which you need for record by record (but this seems to be very inefficient..).
Or someone else can provide a more streamlined approach?
The coldStart trap's parameters - Whats going on and how do I find out what they should be
Hello, I'm new to SNMP, and have a simple question. I'm trying to send a coldStart trap to another system. The coldStart trap's OID is 1.3.6.1.6.3.1.1.5.1
Here is the coldStart's description in the mib:
coldStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A coldStart trap signifies that the SNMP entity,
supporting a notification originator application, is
reinitializing itself and that its configuration may
have been altered."
::= { snmpTraps 1 }
Clear thus far. Now, I'll try to send the trap:
# snmptrap -v 2c -c public otherLinuxSystem SNMPv2-MIB::coldStart
and this command returns:
Missing trap-oid parameter
What? Theres nothing in the mib about parameters. So, I googled, and I found adding a value, 0 in this case:
# snmptrap -v 2c -c public otherLinuxSystem SNMPv2-MIB::coldStart 0
Works. 1 or 2 works too. Heres my questions:
Do all traps have a parameter and its just implied? Is this defined somewhere I missed? How do I know what values represent what? what does 0, 1, and 2 mean in this case, and how can I find this myself in the future? Thanks.
The issue you observe is nothing specific to coldStart, but is just an issue of mistaken usage of net-snmp's snmptrap command. If you look at the bottom of the usage info if you call "snmptrap" with no parameters, you'll see:
-v 1 TRAP-PARAMETERS:
enterprise-oid agent trap-type specific-type uptime [OID TYPE VALUE]...
or
-v 2 TRAP-PARAMETERS:
uptime trapoid [OID TYPE VALUE] ...
You specified -v 2c in your argument, so snmptrap expects the second form. That is, two arguments required after the target address (otherLinuxSystem in your example): a value for sysUpTime.0 and a value for snmpTrapOID.0 that will be included in the trap (I suspect the arguments are swapped in your second example).
The first indicates when the trap occurred and the second identifies the trap itself. Both are required variables in all SNMPv2c/v3 traps; it just happens that net-snmp's snmptrap requires you to specify both of these (rather than, say, defaulting to the host's uptime for sysUpTime.0 if unspecified).