Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Thomas Renninger]

Pallipadi, Venkatesh wrote:
>>-----Original Message-----
>>From: linux-kernel-owner@xxxxxxxxxxxxxxx 
>>[mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of 
>>Stefan Seyfried
>>Sent: Sunday, August 07, 2005 10:43 PM
>>To: Con Kolivas
>>Cc: tony@xxxxxxxxxxx; ck@xxxxxxxxxxxxxxx; 
>>tuukka.tikkanen@xxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; 
>>tytso@xxxxxxx
>>Subject: Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)
>>
>>Con Kolivas wrote:
>>
>>>>When I enabled dynamic tick using:
>>>>
>>>>	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
>>>>
>>>>The number of ticks dropped down to 60-70 HZ, bus mastering activity
>>>>jumpped up to being almost always active,
>>>Anyone know why this would happen?
>>This is just a guess, without any actual code-reading:
>>Maybe the C-state decision process just relies on being called every
>>tick, so "after X ticks with no BM activity, go to next deeper 
>>C state".
>>As long as 1000 ticks per second are coming in, everything is fine and
>>we enter C[n+1] after X miliseconds without BM activity. Now if there
>>are only 60-70 ticks per second, you never get X ticks without BM
>>activity so you never go deeper than C2.
>>
>>Just a guess.
> 
> That is correct. The C-state policy right now looks at jiffies to decide
> on which C-state to go to (instead of absolute time).
> This patch from Thomas should help with respect to going to proper 
> C-state in presence of dynamic tick.
> http://lkml.org/lkml/2005/4/19/96
> 
My patch considered only the average last idle times and the average last bus master
activities.
It could happen that C3/C4 comes in too fast (not waiting long enough for bus master
activity to settle down) which could result in failed transitions or misfunctionality
of bus master devices.
However, it worked on my machine and I could gain a lot of power savings.
But be prepared that your WLAN card, USB peripherie or others might behave strangely or even that
the machine freezes (if, it should freeze quite fast if idle).
I plan to have a look at x86 and x86_64 dynamic tick patches again and rewrite the C-state
patch, soon.
Any hints on updated dyn-tick patches/projects crawling around are appreciated.

Thanks,

   Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/