On Wed, 2009-02-25 at 23:06 -0500, Yaroslav Halchenko wrote: > Hi Ben, > > Thanks -- that is a nice pointer (i.e. /proc/sched_debug), but I still > can't match everything up in my mind... could you gimme a little hint? > > I guess the .clock (in sched_debug) is the interesting one, but it > doesn't match up to the "time" reported by the kernel... > > $> sudo tcpdump -i bond0 -tt -vvv -n "(dst host raider or src host raider)" > -s 192 | head -3; dmesg | tail -1; grep -e 'now' -e '\.clock' > /proc/sched_debug ; echo -n "date :"; date +'%s.%N'; echo -n "uptime:"; cat > /proc/uptime > 1235620965.207560 IP (tos 0x0, ..... > ... > [259941.257724] device eth1 left promiscuous mode > now at 250362660.852703 msecs > .clock : 250362660.973307 > .clock : 250362661.008877 > .... > date :1235620965.387909070 > uptime:250362.67 232514.99 > > so indeed /proc/uptime is close (or is) what is in .clock in sched_debug, > but how could I get those 259941.257724? I am sorry if that is > something obvious and RTFM
Sorry, I thought the clocks shown in sched_debug matched the log timestamps, but I was wrong. I think the divergence is a result of cross-processor interactions, and my machine only has a single processor. Grepping the kernel source suggests that there is currently no way to read the current value of the clock used by printk from user-space. If you are prepared to write a kernel module then you can get the value in nanoseconds for a particular CPU using cpu_clock(cpu_id). Ben.
signature.asc
Description: This is a digitally signed message part
