Date: Wed, 02 Jan 2013 07:02:54 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Alexander Motin <mav@freebsd.org> Cc: Davide Italiano <davide@freebsd.org>, Marius Strobl <marius@alchemy.franken.de>, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [RFC/RFT] calloutng Message-ID: <1357135374.54953.150.camel@revolution.hippie.lan> In-Reply-To: <CAO4K=PUHAH=UNzMde0V2TwkN5vj3gw9hHj5yCQxDvdUn%2Buqv7w@mail.gmail.com> References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <CAO4K=PUHAH=UNzMde0V2TwkN5vj3gw9hHj5yCQxDvdUn%2Buqv7w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2013-01-02 at 15:11 +0200, Alexander Motin wrote: > 02.01.2013 14:28 пользователь "Luigi Rizzo" <rizzo@iet.unipi.it> написал: > > > > On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote: > > > On 02.01.2013 12:57, Luigi Rizzo wrote: > > First of all, if you know that there is already a hardclock/statclock/* > > scheduled in [T_X, T_X+D] you just reuse that. This particular bullet > > was ""no event scheduled in [T_X, T_X+D]" so you need to generate > > a new one. > > That is true, but my main point was about merging with external events, > which I can't predict and the only way to merge is increase sleep period, > hoping for better. > This really is the crux of the problem, because you can't *by default* dispatch an event earlier than requested because that's just a violation of the usual rules of precision timing (where you expect to be late but never early). Sometimes there is no need for such precision, and an early wakeup is no more or less detrimental than a late wakeup. In fact, that may even be the majority case. I wonder if it might make sense to allow the precision specification to indicate whether it needs traditional "never early" behavior or whether it can be interpretted as "plus or minus this amount is fine." Like maybe negative precision is interpretted as "plus or minus abs(precision)" or something like that. Or maybe even the other way around... you get "plus or minus" precision by default and the few things that really care about precision timing have a way of indicating that. (But in that case the userland sleeps would have to assume the traditional behavior because that's how they've always been documented.) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1357135374.54953.150.camel>