Re: [9fans] sleep(2) historical question

[erik quanstrom <quanstro@quanstro.net>]

> > None of the applications look likely to need microsecond let alone
> > nanosecond resolution, and that seems reasonable to me.
> > One exception is sleep(0), but that's yield()
> 
> Chicken and egg.

i think so.

> > > None of the applications look likely to need microsecond let alone
> > > nanosecond resolution, and that seems reasonable to me.
> > > One exception is sleep(0), but that's yield()
> > 
> > you haven't explained how one can emulate a sub-ms
> > sleep with the edf scheduler.  i've got a legit problem.
> 
> Why not add nsleep() with sleeptime in nanosecond units?  And
> of course, any necessary kernel changes for better accuracy.

as it turns out, for anything i had in mind, the kernel already can
do about 10x what i need.  i need maybe 500µs, and i can get 50µs
at 4% error.

the only problem i see with just adding nsleep is it introduces a
second time base, and potentially any time-based call (tsemacquire)
would need to be doubled.  i would prefer for the end state to be
1 user space time base.  but the difficulty is getting there.  at the
least, the syscall# would change.

> The whole idea of a kernel HZ clock seems a bit outdated now.
> If the system has nothing do for the next N seconds, it should
> may be go into low-power mode & just wait for an interrupt.

and when you have things to do, the hz clock is just an unnecessary
interruption.

- erik