Re: [PATCH] dynamic tick patch

[Tony Lindgren]

* Andrea Arcangeli <andrea@xxxxxxx> [050119 09:49]:
> On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
> > HZ=100 does not allow improving the idle loop much further
> > from what we have. We should be able to take advantage of the
> > longer idle/sleep periods inbetween the skipped ticks.
> 
> OTOH servers aren't just doing idle power saving, if you're computing
> wasting 1% of your cpu isn't always desiderable.

That's true, this is more for battery operated systems. In the
current patch there's not that much extra calculation going on when
the system is busy, but there is some overhead.

> You'd need to trap into add_timer to make it a truly dynamic timer, only
> then it would obsolete the HZ=100. So if there's no timer you run at
> HZ=100, while if there's some timer pending in the next 10 timer queues
> you run at HZ=1000.

OK, that makes sense.

> The main problem I can see with your patch is the accuracy issue with
> the system time. I couldn't fix the algorithm you're depending on to get
> accurate system time, and I can guarantee such algorithm never worked
> accurately here and worst of all it doesn't printk anything (which is
> why it doesn't printk for your patch), so you only see system time go in
> the future at an excessive rate (minutes per hour IIRC).

Sounds like for some reason it does not work on your computer then.
I've tried it only on four different machines here, with one SMP
box, and it works fine here. And the debug printk works too, and
time is accurate.

If you have a chance, can you please provide me with some more info
on your system, see my recent reply to Pavel in this thread for the
tests I've been using. Sounds like your system won't boot well enough
to carry out the tests though...

> Pavel posted the cli/sti script, that should allow to reproduce the
> inaccuracy of the algorithm. I had to set HZ=100 by hand to workaround
> the usb modem irq latency that is about 3/4 msec.

Great, I'd like to try it out here.

> Once in a while such algorithm overstates the number of ticks that have
> been missed, and so the system time goes 1msec in the future when that
> happens. I still suspect there might be a bug in such code though.
> There's an unfixable window between the latch read and the tsc
> read where an error can happen, but as long as the window is below
> 0.5msec, it should always be possible to regenerate the accurate timing
> with the current algo, but in practice it fails to be accurate...

Sure there's a lot of room for improvment, but it works quite
accurately here.

Tony
-
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/