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
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 bon
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:
>
> * Diffe
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 mo
4 matches
Mail list logo
