Re: [PATCH 01/13] hrtimer: round up relative start time

[Ingo Molnar <mingo@elte.hu>]

* Roman Zippel <zippel@linux-m68k.org> wrote:

> > This adds an artificial offset to the expiry time, for what reason? The
> > expiry code makes sure that timers can not expire early. See:
> > 
> > 	timer = rb_entry(node, struct hrtimer, node);
> > 	if (now.tv64 <= timer->expires.tv64)
> > 		break;
> > 
> > in kernel/hrtimers.c:run_hrtimer_queue(), where now is already tick
> > aligned.
> > 
> > Please provide a testcase (or detailed use-case) which proves that this
> > is necessary.
> 
> Let's assume a get_time() which simply returns xtime and so has a 
> resolution of around TICK_NSEC. This means the real time when one 
> calls get_time() is somewhere between xtime and xtime+TICK_NSEC.  
> Assuming the real time is xtime+TICK_NSEC-1, get_time() will return 
> xtime and a relative timer with TICK_NSEC-1 will expire immediately. 
> The old code did this correctly. For most hardware this is not a real 
> issue, as the delivery time is larger than the clock resolution, but 
> unless you can guarantee it's not an issue on _any_ supported 
> hardware, this fix is needed. As I already said this can be better 
> fixed as soon as we have a better clock abstraction, until then this 
> is only restores the old behaviour.

but there is no 'old behavior' to restore to. The +1 to itimer intervals 
caused artifacts that were hitting users and caused 2.4 -> 2.6 itimer 
regressions, which hrtimers fixed. E.g.:

  http://bugzilla.kernel.org/show_bug.cgi?id=3289

so i dont think restoring the first timeout of an interval timer to be 
increased by resolution [which your patch does] has any meaning. It 
'restores' to half of what 2.6 did prior hrtimers. Doing that would be 
inconsistent and would push the 'sum-up' errors observed for interval 
timers above to be again observable in user-space (if user-space does a 
series of timeouts). What's the point?

	Ingo