Messages in this thread | | | Date | Mon, 13 Feb 2006 12:25:42 +0100 (CET) | From | Roman Zippel <> | Subject | Re: [PATCH 01/13] hrtimer: round up relative start time |
| |
Hi,
On Mon, 13 Feb 2006, Thomas Gleixner 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.
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/
| |