Re: nanosleep() for shorted than schedule slice

[Johnny Billquist <bqt%softjar.se@localhost>]

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

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