On Sat, Aug 09, 2008 at 03:06:55PM +0200, Alain Guibert wrote:
> > I have tried to play with nanosleep() and it's possible minimize the
> > busy wait. See the experimental patch below
>
> Problem. The delay loop randomly does one of three things:
>
> -1) Sleep, wake before target time, busywait a little complement, exit
> in perfect time. All is well.
>
> -2) Don't sleep. Busywait all the time, during around half a second.
>
> -3) Sleep, wake too late by several milliseconds, resync, and then
> busywait during an whole second.
2) and 3) are happen because
if (0.5 - tdiff - resol > 0)
does not expect a longer tdiff (but after resync it's around 1 sec.).
It shouldn't be difficult to fix this problem.
> The overshoot in sleeping was expectable. The theory may well say one
> timeslice max, but practice doesn't agree. Experiments show that a
> margin of 22 milliseconds seems necessary to be safe on most platforms.
22 is probably a right estimation. BTW, man nanosleep:
Therefore, nanosleep() pauses always for at least the
specified time, however it can take up to 10 ms longer than
specified until the process becomes runnable again.
> > Maybe we need something like
> > foo = set_hardware_clock_prepare()
> > do
> > ....
> > while (newhwtime == sethwtime + (int) (tdiff + 0.5))
> > set_hardware_clock(newhwtime, universal, testing, foo)
>
> Probably insuficient. Between the loop and RTC_SET_TIME, it's a time
> critical path. Any single instruction left there is an instruction too
> much. Optimally the loop should be at the closest, inside of
> set_hardware_clock_rtc(). And for --directisa inside of cmos_set_time(),
> just before the restart of the oscillator (but outside of atomic()).
OK. Sounds good. Any volunteer around?
(I have to work on mount(8) next week.)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
