A few commits ago, an attempt to speed the map look up was done.
Unfortunatly, it was missing the case where you actually hit the speed
up (once the map is the first element of the array, you never return
it).
So, make sure that if i is 0, you return the first element of array,
while still doing the array reordering is i > 0.
perf lets you decide to only get events that concerns a single process
and thus make sysprof profile this process instead of the whole system
(it can happen that you don't really care about other processes that are
just then noise).
As a side effect, this allows sysprof to not run as root if you have the
rights on the process you want to profile.
It has issues on various architectures, such as ARM, and there was
never any guarantee that it would actually work. So since we'd need
fallback code anyway, and the main point of it was simplifying the
code, just get rid of it and handle the overflow conditions manually.
Currently, sysprof hardwires the syscall number of
__NR_perf_counter_open. That's all very well, except... like other
syscall numbers, it varies per-arch. With a few exceptions
(e.g. sparc64), it even varies between 32-bit and 64-bit x86 arches.
This patch provides the defines for every number I could see assigned
in git trunk right now, with the exception of some of the ARM ones, where
I couldn't see how to differentiate between the various sorts of ARM to
figure out what the syscall base was. For those, let's wait for libc to
catch up.
The only arch I've been unable even to guess at is the very new S-Core,
which is the only user so far of the generic syscall table in
<include/asm-generic>. This specifies a value of 241, but I can't hook
it up because I can't find an S-Core toolchain anywhere so I don't know
what #define to check for, and googling gives no clues.
Only tested on x86-64 (where it now works) so there may be all sorts of
bugs in the rest of it (well, in the #defines anyway, though most were
checked against GCC trunk).
If hardware counters are not available, fall back to SW regardless of
why the hardware counters aren't available. The error code can be
either ENOTSUPP or ENODEV depending on CPU type, so it's simpler to
just retry in all cases, and only fail if the software fallback
failed.
There is a bug in the kernel where it includes the stack of the IRQ
that generated the event, so that the stack ends up looking like this:
[ip] [irq stack] [real stack].
As a temporary workaround, this patch filters out the irq stack
symbols.
Accessibility prevents sysprof from working reliably, so disable
it. Specifically, it
- causes large amounts of time to be spent in sysprof itself
whenever the label is updated.
- sometimes hangs at shutdown
- does long-running roundtrip requests that prevents
reading the event buffers, resulting in lost events.
