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

freebsd-arch@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"