Date: Mon, 09 Dec 1996 17:53:54 -0800 From: Jonathan Stone <jonathan@DSG.Stanford.EDU> To: Chris G Demetriou <Chris_G_Demetriou@auchentoshan.pdl.cs.cmu.edu> Cc: Jason Thorpe <thorpej@nas.nasa.gov>, John Birrell <jb@cimlogic.com.au>, terry@lambert.org, hackers@freebsd.org, tech-kern@netbsd.org Subject: i386 priority levels Message-ID: <199612100153.RAA04644@Pescadero.DSG.Stanford.EDU>
next in thread | raw e-mail | index | archive | help
[alpha references snipped; the 2^10-Hz alpha clock-tick "hz" was why I referred to millisecond accuracy] Quoting cgd: >Granted, that doesn't change what you're saying re: scheduling, but >when you add in the fact that the Alpha uses a 1024Hz real time clock >interrupt rate, which could be easily increased, well, you're still in >microseconds for scheduling, but are getting closer. It's just a >matter of time. 8-) Uh, ``of course.''. That's why i also said: >Clearly we should add a nano-second resolution poll interface. >Once we do so, regardless of the actualy in-kernel resolution, >poll(2) and upoll(3) become poll(3) and upoll(3). (the "y" is a typo.) In case it's not clear, the reason for adding nanosecond resolution is that NetBSD has acquired POSIX .12(?)-compatible syscalls with nanosecond resolution, and if we're going to change poll(2) to higher resolution, I'm saying move it to nanoseconds _now_, for consistency with other nanosecond-granularity syscalls, even if the internal implementation doesn't offer better than millisecond (or 100s of microsecond) resolution for some time to come.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612100153.RAA04644>