> > 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
