Messages in this thread | | | Date | Tue, 14 Feb 2006 11:18:09 +0100 (CET) | From | Roman Zippel <> | Subject | Re: [PATCH 01/13] hrtimer: round up relative start time |
| |
Hi,
On Tue, 14 Feb 2006, Ingo Molnar wrote:
> > 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. > > i agree that on systems where get_time() has a TICK_NSEC resolution, > such short timeouts are bad. > > i dont agree with the fix though: it penalizes platforms where > ->get_time() resolution is sane.
How do you want to tell one from the other? Can we agree, that this is the behaviour 2.6 currently already has anyway? I fully agree, that this patch is not the best solution, but is it really such a problem that we can't postpone the behaviour change for a short while until we can fix it properly (i.e. via a proper clock framework)?
bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |