On Wed, Oct 17, 2007 at 03:43:01PM -0400, Hrishikesh wrote:
> for the case where the kernel is patched, but NO_HZ is __not__ enabled,
> there is a do_nanosleep() every 100 or so us.
>
> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}},
> {it_interval={0, 0}, it_value={0, 0}}) = 0
>
On 10/23/07, Jeff Dike <[EMAIL PROTECTED]> wrote:
>
> On Tue, Oct 23, 2007 at 04:21:03PM -0300, Hrishikesh wrote:
> >> Yes, that double negative was a slipup. I did get some numbers out and
> they
> >> look pretty good. I ran upto 5 instances of UML simultaneously and in
> the
> >> tickful case, ea
On Tue, Oct 23, 2007 at 04:21:03PM -0300, Hrishikesh wrote:
> Yes, that double negative was a slipup. I did get some numbers out and they
> look pretty good. I ran upto 5 instances of UML simultaneously and in the
> tickful case, each instance adds roughly about 100 wakeups per second.
HZ == 100,
Hey Jeff,
Yes, that double negative was a slipup. I did get some numbers out and they
look pretty good. I ran upto 5 instances of UML simultaneously and in the
tickful case, each instance adds roughly about 100 wakeups per second. So
after 5 instances, C3 residency comes down to about 95% when all
On Wed, Oct 17, 2007 at 07:29:47PM -0400, Hrishikesh wrote:
> No, I think I haven't been clear enough. The story is right :-) When it is
> "busy-looping" like in the second case is when the C3 residency comes down,
> as expected. Like you said, it looks broken, and has to be fixed.
Yes, your origi
Jeff,
>From looking at the straces, I think it is breaking because in
default_idle(), when we call disable_timer(), it always returns 0 which
means that idle_sleep() and hence nanosleep() are being called with "0
nsecs". This naturally causes the almost busy-loop. I can't quite put my
finger on whe
No, I think I haven't been clear enough. The story is right :-) When it is
"busy-looping" like in the second case is when the C3 residency comes down,
as expected. Like you said, it looks broken, and has to be fixed.
Regards,
Hrishikesh
On 10/17/07, Jeff Dike <[EMAIL PROTECTED]> wrote:
>
> On Wed,
On Wed, Oct 17, 2007 at 03:43:01PM -0400, Hrishikesh wrote:
> Ok the straces do seem to tell the story; they follow below:
Except they're telling the wrong story:
> for the case where is the kernel is patched and NO_HZ enabled,
> {it_interval={0, 0}, it_value={0, 91986}}) = 0
> nanosleep({0, 919
Ok the straces do seem to tell the story; they follow below:
for the case where is the kernel is patched and NO_HZ enabled,
waitpid(3989, [{WIFSTOPPED(s) && WSTOPSIG(s) == 133}], WSTOPPED) = 3989
gettimeofday({1192649136, 409637}, NULL) = 0
gettimeofday({1192649136, 409698}, NULL) = 0
setitimer(I
On Wed, Oct 17, 2007 at 12:16:18PM -0400, Hrishikesh wrote:
> This is when I patch the UML kernel with the NO_HZ patches that you put up
> last month.. on 2.6.23-rc6-mm1.
Hmmm, that's exactly the opposite of what I would expect. A idle
non-NO_HZ UML should be waking up 100 times/sec, while I see
Jeff,
This is when I patch the UML kernel with the NO_HZ patches that you put up
last month.. on 2.6.23-rc6-mm1. Powertop is running on the host kernel and
tells you which process wake up the processor from idle the most and also
which the offending function is (in this case, it shows it to be
do_n
On Tue, Oct 16, 2007 at 10:36:39PM -0400, Hrishikesh wrote:
> When running powertop, I notice that there is a dramatic drop in C3 state
> residency when running the patched kernel. This happens when you run a
> patched kernel but without the NO_HZ and HR timers options disabled. C3
> state residenc
When running powertop, I notice that there is a dramatic drop in C3 state
residency when running the patched kernel. This happens when you run a
patched kernel but without the NO_HZ and HR timers options disabled. C3
state residency drops from about 90% to 50% when the UML kernel is idle.
This does
13 matches
Mail list logo
