Date: Tue, 10 Dec 1996 11:20:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jonathan@DSG.Stanford.EDU (Jonathan Stone) Cc: thorpej@nas.nasa.gov, jb@cimlogic.com.au, terry@lambert.org, hackers@freebsd.org, tech-kern@netbsd.org Subject: Re: poll(2) Message-ID: <199612101820.LAA04523@phaeton.artisoft.com> In-Reply-To: <199612100109.RAA04353@Pescadero.DSG.Stanford.EDU> from "Jonathan Stone" at Dec 9, 96 05:09:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Just wanted to get tech-kern@netbsd.org on this thread, too :-) > > > >"Discuss." :-) > > Uh, well, then.... > > AFAIK, there aren't yet any NetBSD ports with significantly > better than millisecond time-of-day-clock (and thus forced process- > scheduling) resolution. So milliseconds are currently as good as > you'll get. > > You can add a syscall specifying a nanosecond interval, but anyone > thinking they're going to get _nano_second-level wakeups is, > currently, deluding themselves. (I still get ~4usec syscall times on > a 200MHz P6.) The Sun SPARCServer 2 also has a timer resoloution of ~4uS; this was tested with itimers + gettimeofday() after timer firing, so it does include significant system call overhead. I think the scheduling limitation of 100Hz limits the guaranteee resoloution to 10ms, at best (gettimeofday() value update frequency for the SVR4 scheduler module... SVID specifies system clock update frequency... SVR4 is not SVID compliant). If a process consumes it's entire quantum, it will not switch for 10ms without kernel preemption based on a timer event being capable of forcing a kernel-level context switch. Practically, this becomes a maximum of: 10ms + min( 10ms, timer_duration) - 1 If the process in line before the timer expiry process consumes its full quantum. This assumes that timer expiry events result in the process moving to the head of the scheduler queue. Really, good timers is the province of kernel preemption -- and extension for RT scheduling support. When I make an setitimer/getitimer call, I am *truly* interfacing into the RT services (which is why they are listed in section "(RT)" in SVID III). > 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). Yes. This is a good idea in general; it shows good future planning. A 550MHz PPC processor is said to be shipping next year... as we approach GHz speds, nS resoloution becomes likely. At the very least, we are talking sub-uS resoloution, which requires those units be used in any case. > Re naming, npoll() is more consistent with the sleep()/usleep() usage. > Does POSIX have anything to say here? No. All of POSIX is permitted to be implemented in libc as nothing more than wrappers. VMS is POSIX compliant, for instance, if you have the VAX C Runtime Environment (well, except the record seek pointer is not advanced after the implied carriage control from a record has been implied into the input stream -- but that's another story). > If we did this _now_ we could, perhaps, reuse the existing syscall > number, since AFAIK poll(2) has never been in an official NetBSD release. Yes. The only conflict is call gate for ABI with some other OS that does poll with which you want binary compatability. Solaris might be one example. It really depends on whether execution classes imply system call interfaces, or not (they should, meaning no conflict). Regards, 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?199612101820.LAA04523>