[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1208862654.7115.228.camel@twins>
Date: Tue, 22 Apr 2008 13:10:54 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: David Miller <davem@...emloft.net>
Cc: kjwinchester@...il.com, mingo@...e.hu, elendil@...net.nl,
torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, efault@....de, richie@...erworld.net,
rjw@...k.pl
Subject: Re: [git pull] scheduler changes for v2.6.26
On Tue, 2008-04-22 at 03:49 -0700, David Miller wrote:
> From: Kevin Winchester <kjwinchester@...il.com>
> Date: Tue, 22 Apr 2008 06:41:47 -0300
>
> > kevin@...khine:~/linux$ ./watch-rq-clock.sh
> > 89.986517
> > 81.033471
> > 76.942776
> > 90.986318
> > 75.988551
> > 85.987089
> > 74.988696
> > 85.987078
> > 73.988858
> > 88.986641
> > 68.989600
>
> The results on my 128-cpu Niagara2 box are even more interesting:
>
> davem@...amba:~$ /bin/bash ./watch-rq-clock.sh
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> ....
>
> I guess this script doesn't work correctly when the cpu
> whose clock value it greps out of /proc/sched_debug is
> in NOHZ mode?
Yeah - looking at the script it seems to look at the last one, so if
indeed that cpu is fully idle its rq clock will be stalled.
The fix that went in right after .25 was that when it came out of nohz
mode rq->clock could catch up 1 jiffy even though it had been out much
longer.
So the interesting thing to know is whether rq->clock properly accounts
for all idle time when the cpu leaves idle mode.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists