From owner-freebsd-chat Wed Oct 25 10:24:49 2000 Delivered-To: freebsd-chat@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 389CA37B4CF for ; Wed, 25 Oct 2000 10:24:45 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id e9PHN7f79089; Wed, 25 Oct 2000 12:23:07 -0500 (CDT) (envelope-from jlemon) Date: Wed, 25 Oct 2000 12:23:07 -0500 From: Jonathan Lemon To: Simon Kirby Cc: Jonathan Lemon , Dan Kegel , chat@freebsd.org, linux-kernel@vger.kernel.org Subject: Re: kqueue microbenchmark results Message-ID: <20001025122307.B78130@prism.flugsvamp.com> References: <20001024225637.A54554@prism.flugsvamp.com> <39F6655A.353FD236@alumni.caltech.edu> <20001025010246.B57913@prism.flugsvamp.com> <20001025112709.A1500@stormix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20001025112709.A1500@stormix.com> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Oct 25, 2000 at 11:27:09AM -0400, Simon Kirby wrote: > On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote: > > > Yes, someone pointed me to those today. I would suggest reading > > some of the relevant literature before embarking on a design. My > > paper discusses some of the issues, and Mogul/Banga make some good > > points too. > > > > While an 'edge-trigger' design is indeed simpler, I feel that it > > ends up making the job of the application harder. A simple example > > to illustrate the point: what if the application does not choose > > to read all the data from an incoming packet? The app now has to > > implement its own state mechanism to remember that there may be pending > > data in the buffer, since it will not get another event notification > > unless another packet arrives. > > What applications would do better by postponing some of the reading? > I can't think of any reason off the top of my head why an application > wouldn't want to read everything it can. Doing everything in smaller > chunks would increase overhead (but maybe reduce latencies very slightly > -- albeit probably not much when using a get_events()-style interface). Consider a program which reads from point A, writes to point B. If the buffer associated with B fills up, then we don't want to continue reading from A. A/B may be network sockets, pipes, or ptys. Or perhaps you receive a request to use a resource that is currently busy. Does your application want to postpone the request, or read the data immediately, even if the request can't be serviced yet? My point is that I can easily think of several examples as to where this behavior may be beneficial to the application, and I use some of them myself. You can indeed get the same result by forcing each and every application that wants this behavior to implement their own tracking mechanism, but this strikes me as error-prone and places an undue burden on the application programmer. > Isn't it probably better to keep the kernel implementation as efficient > as possible so that the majority of applications which will read (and > write) all data possible can do it as efficiently as possible? Queueing > up the events, even as they are in the form received from the kernel, is > pretty simple for a userspace program to do, and I think it's the best > place for it. I don't believe that you must sacrifice efficiency to achieve this goal, I think that you can provide both forms in an efficent fashion. > I know nothing about any other implementations, though, and I'm speaking > mainly from the experiences I've had with coding daemons using select(). > You mention you wrote a paper discussing this issue...Where could I find > this? I'm also speaking from experience, from using various forms of event notification. kqueue() is actually a 3rd generation system, building off the experience I had with the first two, along with other input. You can find my paper at http://people.freebsd.org/~jlemon -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message