Date: Wed, 8 Sep 1999 18:44:38 -0700 From: "Justin C. Walker" <justin@apple.com> To: freebsd-hackers@freebsd.org Subject: Re: message queues for I/O (usenix paper) Message-ID: <199909090144.SAA02454@rhapture.apple.com>
next in thread | raw e-mail | index | archive | help
> From: Jayson Nordwick <nordwick@scam.xcf.berkeley.edu> > Date: 1999-09-08 17:38:56 -0700 > To: freebsd-hackers@FreeBSD.ORG > Subject: message queues for I/O (usenix paper) > Content-id: <66138.936837476.1@scam.XCF.Berkeley.EDU> > Delivered-to: freebsd-hackers@freebsd.org > X-Loop: FreeBSD.ORG > > There is alot of talk going on over at the linux-kernel mailing list > about implementing synchronous messaging for I/O. They are talking about > a paper that was presented at USENIX: > > http://www.cs.rice.edu/~gaurav/papers/usenix99.ps > > The general idea is that select() and poll() fall over with large numbers of > file descriptors for two reasons. First, scanning the interest list begins to > consume more time. Second, the stateless nature between calls means that > alot of redundant processing occurs. The solution these guys (the authors) > say is to have a way of registering interest in descriptors, then you can > call a procedure to find out what has changed since last time. > > I personally think that select() is just fine and can be implemented > more efficiently than currently, but I would be willing to give it a shot > at both cooperating with the Linux people to get a good Linux/FreeBSD > API layed down and then implementing it. > > I know some of you heard this paper presented so does anybody have any > ideas about it? > > Does anybody care? >From the FWIW department, we have, in the Darwin source, an implementation of a "select replacement" that is designed to get around some of the (perceived or real) issues with select(), e.g., looking at a long (FD_SETSIZE or larger) array of bits several times in the kernel and in user space. In the available sources, this is represented in sys/ev.h, and is implemented only for sockets. Our tests indicate a roughly 5-10% speed improvement when a lot of sockets are in use but not exuberantly so. For Darwin in the future (the Core OS for Mac OS X), this scheme will be somewhat generalized, to provide a uniform mechanism for fielding events from any subsystem. It will be made more interesting by the need to incorporate mach message handling in addition to file-descriptor-based events. Have a look, should this be of interest. I'll be happy to field questions, since the doc is a bit, oh, scant... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909090144.SAA02454>