lkml.org 
[lkml]   [2013]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/RFC] wait_for_completion_timeout() considered harmful.
On Tue, 19 Nov 2013, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 07:58:51PM +1100, NeilBrown wrote:
> > /*
> > * TODO: Make sure that we wait at least required delay but why we
> > * have to extend it one tick more?
> > */
> > schedule_timeout_interruptible(msecs_to_jiffies(delay) + 2);
>
> What makes me sad is that clearly people knew stuff was broken but
> somehow it never got properly fixed.
>
> Yes, changing something like this is risky, but I prefer to fix the
> implementation to the sane and documented behaviour and fix up whatever
> fallout that generates. The end result is saner code in general and less
> new bugs.

The underlying issue of the timer wheel is that it is driven by a
coarse grained tick.

So a schedule_timeout(1) is guaranteed to sleep until the next tick
arrives. There is no way to figure out whether the timer was started
right at the beginning of a tick period or right at the end.

This has been the case from day one of the timer wheel.

The user space interfaces [clock_]nanosleep and the various posix
timers had countermeasures based on gettimeofday() to guarantee the
correct behaviour. glibc still has some extra checks around some
timeout related syscalls for that reason. We killed that mess when we
converted them over to hrtimers.

So if you really want to make sure that you slept at minimum the given
number of ticks with the timer wheel, then you have only one choice:

Add unconditionally 1 to the given number of ticks

I don't think that this will cause a massive fallout as the timing of
the timer_list timers already varies by an order of magnitude due to
the HZ settings. So anything which relies on the timer wheel in terms
of precision is hosed already. So adding 1 will just hose it some
more.

Thanks,

tglx


\
 
 \ /
  Last update: 2013-11-19 16:01    [W:0.060 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site