tech-kern archive

[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: (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 tick-based system.

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:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index