An error occurred fetching the project authors.
- 06 Apr, 2009 23 commits
-
-
Mike Galbraith authored
Decouple kerneltop display from event acquisition by introducing a separate data acquisition thread. This fixes annnoying kerneltop display refresh jitter and missed events. Also add a -r <prio> option, to switch the data acquisition thread to real-time priority. Signed-off-by:
Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Orig-LKML-Reference: <new-submission> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Peter Zijlstra authored
Go along with the new perf_event_type ABI. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Paul Mackerras <paulus@samba.org> Orig-LKML-Reference: <20090330171024.133985461@chello.nl> Signed-off-by:
-
Paul Mackerras authored
Impact: new functionality This adds add an option to the perfstat mode of kerneltop to scale the reported counter values according to the fraction of time that each counter gets to count. This is invoked with the -l option (I used 'l' because s, c, a and e were all taken already.) This uses the new PERF_RECORD_TOTAL_TIME_{ENABLED,RUNNING} read format options. With this, we get output like this: $ ./perfstat -l -e 0:0,0:1,0:2,0:3,0:4,0:5 ./spin Performance counter stats for './spin': 4016072055 CPU cycles (events) (scaled from 66.53%) 2005887318 instructions (events) (scaled from 66.53%) 1762849 cache references (events) (scaled from 66.69%) 165229 cache misses (events) (scaled from 66.85%) 1001298009 branches (events) (scaled from 66.78%) 41566 branch misses (events) (scaled from 66.61%) Wall-clock time elapsed: 2438.227446 msecs This also lets us detect when a counter is zero because the counter never got to go on the CPU at all. In that case we print <not counted> rather than 0. Signed-off-by: -
Peter Zijlstra authored
frob the kerneltop code to print the mmap data in the stream Better use would be collecting the IPs per PID and mapping them onto the provided userspace code.. TODO Signed-off-by:
-
Peter Zijlstra authored
Now that the kernel side changed, match up again. Signed-off-by:
-
Peter Zijlstra authored
Teach kerneltop about the new output ABI. XXX: anybody fancy integrating the PID/TID data into the output? Bump the mmap_data pages a little because we bloated the output and have to be more careful about overruns with structured data. Signed-off-by:
-
Peter Zijlstra authored
provide a knob to set the number of mmap data pages. Signed-off-by:
-
Peter Zijlstra authored
Paul Mackerras wrote: > I noticed the poll stuff is bogus - we have a 2D array of struct > pollfds (MAX_NR_CPUS x MAX_COUNTERS), we fill in a sub-array (with the > rest being uninitialized, since the array is on the stack) and then > pass the first nr_cpus elements to poll. Not what we really meant, I > suspect. :) Not even if we only have one counter, since it's the > counter dimension that varies fastest. This should fix the most obvious poll fubar.. not enough to fix the full problem though.. Reported-by:
-
Paul Mackerras authored
The glib dependency in kerneltop.c is only for a little bit of list manipulation, and I find it inconvenient. This adds a 'next' field to struct source_line, which lets us link them together into a list. The code to do the linking ourselves turns out to be no longer or more difficult than using glib. This also fixes a few other problems: - We need to #include <limits.h> to get PATH_MAX on powerpc. - We need to #include <linux/types.h> rather than have our own definitions of __u64 and __s64; on powerpc the installed headers define them to be unsigned long and long respectively, and if we have our own, different definition here that causes a compile error. - This takes out the x86 setting of errno from -ret in sys_perf_counter_open. My experiments on x86 indicate that the glibc syscall() does this for us already. - We had two CPU migration counters in the default set, which seems unnecessary; I changed one of them to a context switch counter. - In perfstat mode we were printing CPU cycles and instructions as milliseconds, and the cpu clock and task clock counters as events. This fixes that. - In perfstat mode we were still printing a blank line after the first counter, which was a holdover from when a task clock counter was automatically included as the first counter. This removes the blank line. - On a test machine here, parse_symbols() and parse_vmlinux() were taking long enough (almost 0.5 seconds) for the mmap buffer to overflow before we got to the first mmap_read() call, so this moves them before we open all the counters. - The error message if sys_perf_counter_open fails needs to use errno, not -fd[i][counter]. Signed-off-by:
-
Ingo Molnar authored
Commit b7368fdd7d decreased the CPU cycles interval 100-fold, but this is causig kerneltop failures on my Nehalem box: aldebaran:/home/mingo/linux/linux/Documentation/perf_counter> ./kerneltop KernelTop refresh period: 2 seconds ERROR: failed to keep up with mmap data 10,000 cycles is way too short. What we should do instead on mostly-idle systems is some sort of read/poll timeout, so that we display something every 2 seconds for sure. Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: -
Ingo Molnar authored
Fix: kerneltop.c: In function ‘record_ip’: kerneltop.c:1005: warning: format ‘%016llx’ expects type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Paul Mackerras <paulus@samba.org> Acked-by:
-
Ingo Molnar authored
Remove now unified perfstat.c and perf_counter.h, and link to the in-kernel perf_counter.h. Cc: Wu Fengguang <fengguang.wu@intel.com> Cc: Paul Mackerras <paulus@samba.org> Acked-by:
-
Peter Zijlstra authored
update kerneltop to use the mmap() output to gather overflow information Signed-off-by:
-
Peter Zijlstra authored
update the kerneltop userspace to work with the latest syscall ABI Signed-off-by:
-
Wu Fengguang authored
Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Acked-by:
-
Wu Fengguang authored
In my system, it takes kerneltop dozens of minutes to show up usable numbers. Make the default count 100 times smaller fixed this long startup latency. I'm not sure if it's the right solution though. Signed-off-by:
-
Wu Fengguang authored
Signed-off-by:
-
Wu Fengguang authored
Signed-off-by:
-
Wu Fengguang authored
- perfstat.c can be safely removed now - perfstat: -s => -a for system wide accounting - kerneltop: add -S/--stat for perfstat mode - minor adjustments to kerneltop --help, perfstat --help Signed-off-by:
-
Wu Fengguang authored
- can handle sw counters now - the outputs will look slightly different Acked-by:
-
Wu Fengguang authored
- kerneltop: --event_id => --event - kerneltop: can accept SW event types now - perfstat: it used to implicitly add event -2(task-clock), the new code no longer does this. Shall we? Signed-off-by:
-
Wu Fengguang authored
kerneltop's MAX_COUNTERS is increased from 8 to 64(the value used by perfstat). Signed-off-by:
-
Ingo Molnar authored
Initial version of kerneltop.c and perfstat.c. Acked-by:
-
