Thread (22 messages) 22 messages, 3 authors, 2012-11-12

Re: scheduler clock for MXS

From: Russell King - ARM Linux <hidden>
Date: 2012-11-08 22:11:13
Also in: linux-arm-kernel

On Thu, Nov 08, 2012 at 10:27:59PM +0100, Stanislav Meduna wrote:
What is actually the reason of round_jiffies there? The
http://kernel.org/doc/htmldocs/device-drivers/API-round-jiffies.html
mentions saving power, is it the only one?

I'd probably just leave the round_jiffies out at least for
wrap_ticks < around 16*HZ. Above that the error by possibly
rounding up can be ignored.

There is also a round_jiffies_up - unless I am too tired, as long as
we tick no faster than once per second, subtracting (HZ-1) and rounding
up should be the same as rounding down.

But: is the round_jiffies* safe at all for sub-second precision
at jiffies around 0xffffffff? From quick looking it does a modulo,
0xffffffff % say 250 is 45, the next jiffy is at 0...
Well, the idea is to avoid having yet another random thing causing yet
another wakeup from the idle modes.  If you've ever watched a LED
indicating when the kernel is in the idle loop and when it isn't,
you'll know exactly what I'm talking about; your normal Linux system
sits there constantly being kicked out of idle several times a second
while... idle to service various kernel tasks.

We really don't want to add to that; if we get enough of these events
happening at random intervals, we will end up with things like cpu idle
being completely thwarted by stuff like this.

As I have said, what we want is a version of round_jiffies() which
rounds down to something, not up.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help