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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox