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
My today reported (and reassigned to linux2.6) bug #517122
doesn't gimme rest. One of the problem of analysis of traces is that
some times are recorded since epoch, some are the kernel's uptime.
what puzzles me is:
* Difference between dmesg timestamp and /proc/uptime
$ tcpdump -i bond0 -tt
I guess kernel/sched_clock.c gave me the answer to the 1st question...
even answered why I saw some timestamps jumping backwards while I was
monitoring debug msgs of RPC + NFS , I guess they came from different
CPUs
now I wonder if there is a tool which would work along some other
process and
On Wed, 2009-02-25 at 20:47 -0500, Yaroslav Halchenko wrote:
My today reported (and reassigned to linux2.6) bug #517122
doesn't gimme rest. One of the problem of analysis of traces is that
some times are recorded since epoch, some are the kernel's uptime.
what puzzles me is:
* Difference
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
5 matches
Mail list logo
