Date: Sun, 19 Nov 1995 17:29:04 +1100 From: Bruce Evans <bde@zeta.org.au> To: cimaxp1!jb@werple.net.au, lambert.org!terry@werple.net.au Cc: hackers@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: DELAY's in syscons Message-ID: <199511190629.RAA22981@godzilla.zeta.org.au>
next 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511190629.RAA22981>