Date: Sun, 2 Dec 2007 05:50:31 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <20071202055031.A8107@xorpc.icir.org> In-Reply-To: <18791.1196602357@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sun, Dec 02, 2007 at 01:32:37PM %2B0000 References: <20071202045134.A7421@xorpc.icir.org> <18791.1196602357@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 02, 2007 at 01:32:37PM +0000, Poul-Henning Kamp wrote: > In message <20071202045134.A7421@xorpc.icir.org>, Luigi Rizzo writes: ... > I think I have also convinced myself to change this to be one > function with a scaling specified: > > #define TIMEOUT_NSEC (1 << 9) > #define TIMEOUT_USEC (1 << 6) > #define TIMEOUT_MSEC (1 << 3) > #define TIMEOUT_SEC (1 << 0) > timeout_time timeout_conv_time(struct timeout_p *, unsigned val, unsigned scale) ; > > > >2. I fully agree that the precision level should be a user-supplied > > parameter, but wonder whether ns/us/ms/s is really the set of > > precisions one might want. I could see a need for at least the > > following requests: > > > > "as accurate as possible" > > "one timecounter tick accuracy, whatever the tick is" > > "one timer tick (1/HZ) accuracy, whatever the tick is" > > " > > Ticks may cease to have importance with hardware like the HPET > where we can implement deadlining instead of periodic scheduling. > > It may make sense to offer ranges or tolerances, but that can be > added later if we find that we need it. > > The goal here and now, in this area of the API, is only to kill HZ > as a specification unit of time. I suppose the goal is to let the program express its real requirements as opposed to "requirements with hardwired assumptions on the timer implementation". So seconds and microseconds etc. are fine in some cases (e.g. playing with hardware, or protocol timeouts, etc.). But in other cases the periodic scheduling is really an application requirement and not an artifact of the hardware - e.g. think of the many drivers or applications that need to do some periodic polling because the hardware doesn't really provide a synchronization signal. In those cases you want to synchronize to what the underlying period is, rather than hardwire your own estimate in the code. This is why i suggest having a 'scale' that can represent '1 tick' (and also don't depend on TIMEOUT_MSEC == 1000 and so on, but keep them opaque and require that the client code uses one of the supported scales). cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071202055031.A8107>