On 05/06/07, Matt Mackall <[email protected]> wrote:
> [...]
> Click into the lguest window and trigger the delay.
I did:
while true; do sleep 1; cat /proc/sched_debug > sched_debug.txt; done
and got this, hopefully inside the window:
Sched Debug Version: v0.02
now at 257428593818894 nsecs
cpu: 0
.nr_running : 3
.raw_weighted_load : 2063
.nr_switches : 242830075
.nr_load_updates : 30172063
.nr_uninterruptible : 0
.jiffies : 64282148
.next_balance : 0
.curr->pid : 27182
.clock : 125650217819008823
.prev_clock_raw : 257428516403535
The delta (clock - prev_clock_raw) looks insane.
The current time (which doesn't depend on rq_clock() --> sched_clock() is
" now at 257428593818894 nsecs " (right at the beginning of the output).
'prev_clock_raw' is updated any time rq_clock() is called - basically
upon any scheduling operation (e.g. enqueue/dequeue)
now - prev_clock_raw == 257428593818894 - 257428516403535 == ~ 80 ms.
while 'clock' reports something crazy.. that would explain why there
wes a huge "block_max" reported earlier.. I guess, sched_clock() is
tsc-based in your case?
Any way to get it switched to jiffies-based one and repeat the test?
--
Best regards,
Dmitry Adamushko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
