From: Dave Jones <davej@redhat.com>
To: Con Kolivas <kernel@kolivas.org>
Cc: ck@vds.kolivas.org,
Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl>,
Arjan van de Ven <arjan@infradead.org>,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.15-ck1
Date: Wed, 4 Jan 2006 19:27:59 -0500 [thread overview]
Message-ID: <20060105002759.GB30967@redhat.com> (raw)
In-Reply-To: <200601051112.52404.kernel@kolivas.org>
On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote:
> On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote:
> > Arjan van de Ven wrote:
> > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
> > >
> > > sounds like we need some sort of profiler or benchmarker or at least a
> > > tool that helps finding out which timers are regularly firing, with the
> > > aim at either grouping them or trying to reduce their disturbance in
> > > some form.
> >
> > You mean something like a modification to timer debugging patch to
> > record the last time the timer fired, right?
> > Timertop could then detect the pattern and provide frequency, standard
> > deviation and other statistical data.
> > It would be much more expensive to test of course.
>
> I don't think the timer debugging patch needs to give out any more info. The
> userspace tool should be able to do this with the amount of info the timer
> debugging patch is giving already.
In the absense of a pointer to a userspace tool, I found the following handy.
(It also fixes a bug where it was printing garbage as process names).
[this is just an opencoded print_address(). I would have used that but it
printk's instead of sprintf's to a buffer which made it useless for use by seq_print]
With this, it prints output like..
cfq_idle_slice_timer+0x0/0xb3 4 0 <kthread>
...
process_timeout+0x0/0x5 1025 147 pdflush
process_timeout+0x0/0x5 1701 3 watchdog/0
it_real_fn+0x0/0x5a 1907 2309 Xorg
process_timeout+0x0/0x5 2896 2356 gdmgreeter
process_timeout+0x0/0x5 3634 1940 python
i8042_timer_func+0x0/0xb 8699 0 <no data>
rh_timer_func+0x0/0x5 16499 4
There's still 1 case though it seems where some timers get garbage printed as their ->comm
If I get motivation to hack on this some more, I'll look further into it, but
this gets me 99% of the way there. (Actually, it's missing timers launched
on behalf of init it seems (they all have a pid of '1'.
Wonder why init hasn't got a sane ->comm though).
Dave
diff -urpN --exclude-from=/home/davej/.exclude linux-2.6.15/kernel/timer_top.c timertop/kernel/timer_top.c
--- linux-2.6.15/kernel/timer_top.c 2006-01-04 19:20:41.000000000 -0500
+++ timertop/kernel/timer_top.c 2006-01-04 18:37:35.000000000 -0500
@@ -27,12 +27,13 @@
#include <linux/spinlock.h>
#include <linux/sched.h>
#include <linux/seq_file.h>
+#include <linux/kallsyms.h>
#include <asm/uaccess.h>
#define VERSION "Timer Top v0.9.8"
struct timer_top_info {
- unsigned int func_pointer;
+ unsigned long func_pointer;
unsigned long counter;
pid_t pid;
char comm[TASK_COMM_LEN];
@@ -88,7 +89,11 @@ int account_timer(unsigned long function
if ((task_info->pid > 0) && (task_info->pid < PID_MAX_LIMIT)) {
pid_info = task_info->pid;
strncpy(name, task_info->comm, sizeof(task_info->comm));
+ } else {
+ strcpy(name, "<kthread>");
}
+ } else {
+ strcpy(name,"<no data>");
}
if (update_top_info(function, pid_info))
@@ -138,12 +143,30 @@ static struct proc_dir_entry *top_info_f
static int proc_read_top_info(struct seq_file *m, void *v)
{
struct timer_top_info *top;
+ char *modname;
+ const char *name;
+ unsigned long offset, size;
+ char namebuf[KSYM_NAME_LEN+1];
+ char buffer[sizeof("%s+%#lx/%#lx [%s]") + KSYM_NAME_LEN +
+ 2*(BITS_PER_LONG*3/10) + MODULE_NAME_LEN + 1];
seq_printf(m, "Function counter - %s\n", VERSION);
list_for_each_entry(top, timer_list, list) {
- seq_printf(m, "%x %lu %d %s\n", top->func_pointer,
- top->counter, top->pid, top->comm);
+
+ name = kallsyms_lookup(top->func_pointer, &size, &offset, &modname, namebuf);
+ if (!name)
+ sprintf(buffer, "0x%lx", top->func_pointer);
+ else {
+ if (modname)
+ sprintf(buffer, "%s+%#lx/%#lx [%s]", name, offset,
+ size, modname);
+ else
+ sprintf(buffer, "%s+%#lx/%#lx", name, offset, size);
+ }
+
+ seq_printf(m, "%s %lu %d %s\n",
+ buffer, top->counter, top->pid, top->comm ? top->comm : "<>");
}
if (!top_root.record)
next prev parent reply other threads:[~2006-01-05 0:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-04 1:00 2.6.15-ck1 Con Kolivas
2006-01-04 19:05 ` 2.6.15-ck1 Dave Jones
2006-01-04 19:57 ` 2.6.15-ck1 Dave Jones
2006-01-04 20:33 ` 2.6.15-ck1 Arjan van de Ven
2006-01-04 21:22 ` 2.6.15-ck1 Dave Jones
2006-01-04 21:40 ` [ck] 2.6.15-ck1 Radoslaw Szkodzinski
2006-01-05 0:12 ` 2.6.15-ck1 Con Kolivas
2006-01-05 0:27 ` Dave Jones [this message]
2006-01-05 0:49 ` 2.6.15-ck1 Con Kolivas
2006-01-05 1:14 ` 2.6.15-ck1 Dave Jones
2006-01-05 1:22 ` 2.6.15-ck1 Andi Kleen
2006-01-05 1:36 ` 2.6.15-ck1 Con Kolivas
2006-01-05 6:04 ` 2.6.15-ck1 Dave Jones
2006-01-05 6:42 ` 2.6.15-ck1 Vojtech Pavlik
2006-01-05 6:55 ` [ck] 2.6.15-ck1 Con Kolivas
2006-01-05 15:19 ` 2.6.15-ck1 Andi Kleen
2006-01-05 16:30 ` 2.6.15-ck1 Vojtech Pavlik
2006-01-05 16:39 ` 2.6.15-ck1 Andi Kleen
2006-01-05 17:13 ` 2.6.15-ck1 Dmitry Torokhov
2006-01-05 17:28 ` 2.6.15-ck1 Andi Kleen
2006-01-05 1:50 ` 2.6.15-ck1 Tony Lindgren
2006-01-04 23:10 ` 2.6.15-ck1 Con Kolivas
2006-01-05 1:57 ` 2.6.15-ck1 Tony Lindgren
2006-01-05 18:47 ` [ck] 2.6.15-ck1 Kevin Radloff
2006-01-12 18:51 ` Daniel Petrini
2006-01-04 20:38 ` 2.6.15-ck1 Grant Coady
2006-01-04 20:56 ` 2.6.15-ck1 Dave Jones
2006-01-12 22:11 ` 2.6.15-ck1 Adam Belay
2006-01-12 23:03 ` 2.6.15-ck1 Dave Jones
2006-01-13 0:42 ` 2.6.15-ck1 Adam Belay
2006-01-13 0:46 ` 2.6.15-ck1 Dave Jones
2006-01-16 20:28 ` 2.6.15-ck1 Ben Slusky
2006-01-14 3:42 ` 2.6.15-ck1 Philipp Rumpf
2006-01-14 4:41 ` 2.6.15-ck1 Dave Jones
2006-01-14 13:06 ` [ck] 2.6.15-ck1 Jens Axboe
2006-01-05 17:58 ` 2.6.15-ck1 Tomasz Torcz
2006-01-05 23:22 ` 2.6.15-ck1 Con Kolivas
2006-01-07 13:16 ` 2.6.15-ck1 Tomasz Torcz
[not found] ` <9268368b0601131119n639c345cgcf2a5dadd7cb423c@mail.gmail.com>
2006-01-14 20:54 ` 2.6.15-ck1 Tomasz Torcz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060105002759.GB30967@redhat.com \
--to=davej@redhat.com \
--cc=arjan@infradead.org \
--cc=astralstorm@gorzow.mm.pl \
--cc=ck@vds.kolivas.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.