From owner-freebsd-hackers Wed Sep 8 18: 3: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 5E47D14BD3 for ; Wed, 8 Sep 1999 18:02:52 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id UAA24971; Wed, 8 Sep 1999 20:02:03 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.8.5/8.6.4) with ESMTP id UAA18426; Wed, 8 Sep 1999 20:02:02 -0500 (CDT) Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id UAA26715; Wed, 8 Sep 1999 20:02:01 -0500 (CDT) Date: Wed, 8 Sep 1999 20:02:01 -0500 (CDT) From: Jonathan Lemon Message-Id: <199909090102.UAA26715@free.pcs> To: nordwick@scam.xcf.berkeley.edu, hackers@freebsd.org Subject: Re: message queues for I/O (usenix paper) X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >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? Yes. I don't particularly like some of the things in the paper, although it does have several good concepts. I have an implementation that does exactly this, and have a line on two other implementations that do the same thing (but in a different fashion). Unfortunately, all of these are somewhat problem-specific and are not a general solution. I've spent some time working on a generic implementation that draws its ideas from several places. I hope to be in a position where I can work on this almost full time within a month. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message