Date: Sun, 19 Nov 1995 15:45:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: cimaxp1!jb@werple.net.au, terry@lambert.org, hackers@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: DELAY's in syscons Message-ID: <199511192245.PAA01724@phaeton.artisoft.com> In-Reply-To: <199511190629.RAA22981@godzilla.zeta.org.au> from "Bruce Evans" at Nov 19, 95 05:29:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Time to scream about high resoloution kernel timers once again? A nice > >> reschedulable one-shot HRT interface would fix DELAY right up. There > >> are only *minor* kernel preemption issues involved. > > >What are the issues about getting better time resolution in general from the > >kernel? With process control software (that is threaded) running flat out in > >memory (no disk or network I/O), we notice the timer resolution. > > >We'd also like a better nanosleep than we get using select. Is nanosleep > >something you'd implement with your "reschedulable one-shot HRT interface"? > > Timer resolution is fine, but select() and usleep() and anything else > that depends on the scheduling clock for wakeups is limited to at most > the resolution of the scheduling clock (1/hz seconds). One shot timers > could be used to improve the select() resolution. They would not be > easy to implement without reducing the accuracy of the kernel time. > They would not help fix DELAY() because DELAY() isn't allowed to sleep. > They might help avoid abuses of DELAY(). They could be used to improve > the resolution of timeout() and tsleep() in the same way as for select(). > Note that only minimum timeouts can be guaranteed. Actually this limitation on what can be guaranteed is *precisely* what I meant when I said "*minor* kernel preemption issues involved". The limit on the guarantee is made by a process being preemptible only at certain times, which means timeout()/tsleep() queues are examined 0 to "ticks per quantum minux one" number of ticks *after* the even. If the event caused a preemption, then the problem would be solved. This assumes that: (1) code calling an HRT is never reentered while the HRT is sleeping (simple to guarantee with a spinlock on the system making the call), and (2) the HRT events are serviced as if they are interrupts. Layering the timeout()/tsleep() on top of the HRT services would be as easy as establishing a queue of events, and queueing the event to be serviced at the normal context switch time instead of as if it were an interrupt. For conflicting events,the one-shot is a countdown, and the event can be converted into a buzz-loop (per "DELAY") or blocked from scheduling (otherwise you get into issues of "deadlining". The first application of such timer services would be to replace spinning in DELAY()'s and thereby increase overall concurrency. The second would be to move some of the rather tight secheduling constraints for things like the "ft" driver into the kernel and throw away the "ft" utility in user space. Etc... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511192245.PAA01724>