[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: nanosleep() for shorted than schedule slice
On 2017-07-03 01:10, Michael van Elst wrote:
bqt%softjar.se@localhost (Johnny Billquist) writes:
A tickless kernel wouldn't run callouts from the regular clock interrupt
but would use a hires timer to issue interrupts at arbitrary times.
The callout API could then be changed to either accept timespec values or
just fake a much higher HZ value.
Right. Not that I believe this have to be tied into tickless, but I
suspect it might be easier to do it if we go tickless.
Well, "not using a regular clock interrupt" is what "tickless" means.
One does not exclude the other.
We really should be able to deal with shorter times, even if we have
That's a contradiction. "ticks" means that timed events are based
on a regular clock interrupt. Of course you can speed up the ticks
(e.g. Alpha uses HZ=1000), but that has other disadvantages.
N.B. going tickless isn't difficult, it's just lots of work as it needs
MD support on all platforms.
There is no conflict in having both. Some things can run based on a
regular tick, while some things are based on hardware timer that
interrupts when the specified time have passed.
That would, by pretty much all definitions I know, still classify as a
It's pretty much just that we have two clock sources. Which is nothing
new, really. And having some things driven by interrupt events is
already the norm for non-clock based events. I believe most hardware
already supports such an idea as well. One low resolution clock which
generates interrupt at something like 100Hz, and one high resolution
clock, which can be programmed to whatever (short) time in the future to
generate an interrupt.
Having the normal wall clock driven by a tick interrupt has its points.
And having things like preemptive context switches based on ticks is
pretty much what you want anyway. With a tickless kernel, you'll have to
set up those ticks anyway.
It's just that for high resolution timers, ticks are not a good source.
For anything else, they are just fine. So why conflate the two?
(Rethorical question, and I won't object if someone just implements a
tickless kernel as well, but it is not as trivial as hinted. You
probably will end up with having such a system run a tick anyway, unless
you want to start calculating wall clock time in all kind of places
under various circumstances, where wall clock is used. But of course,
it's all doable.)
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Main Index |
Thread Index |