From owner-freebsd-arch Thu Apr 6 23:30:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 68C5B37C23C for ; Thu, 6 Apr 2000 23:30:46 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA17424 for ; Fri, 7 Apr 2000 08:34:21 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA35598 for freebsd-arch@freebsd.org; Fri, 7 Apr 2000 08:30:45 +0200 (CEST) Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id BAD8B37BA18 for ; Thu, 6 Apr 2000 23:30:34 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.9.3/8.9.3) id BAA47221; Fri, 7 Apr 2000 01:33:58 -0500 (CDT) (envelope-from jlemon) Date: Fri, 7 Apr 2000 01:33:58 -0500 From: Jonathan Lemon To: Matthew Dillon Cc: Jonathan Lemon , Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000407013358.P80578@prism.flugsvamp.com> References: <200004070107.SAA97591@bubba.whistle.com> <200004070220.TAA92896@apollo.backplane.com> <20000406220454.J80578@prism.flugsvamp.com> <200004070401.VAA93492@apollo.backplane.com> <20000406234905.K80578@prism.flugsvamp.com> <200004070510.WAA93968@apollo.backplane.com> <20000407003819.O80578@prism.flugsvamp.com> <200004070547.WAA94276@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200004070547.WAA94276@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 06, 2000 at 10:47:19PM -0700, Matthew Dillon wrote: > : > :> I don't understand your comment about 'binding the implementation'. > :> No such thing is occuring. Sure, the user structure has to stay around.. > :> that's not a big deal, it's how aio works. It certainly does not > : > :Yes, but that's not how this necessarily works, it isn't AIO. I can > :create a huge buffer to copy in 10,000 events at once, and then read > :events out into another buffer in chunks of 100 if I want. I don't > :necessarily have to, in fact I definitely *don't* want to keep the > :original structures around where I copied data from. > > If you have 100 events which would you rather do: > > (1) Pass an array of 100 kevent structures, each 16 bytes, and > have to copyout 16x100 = 1600 bytes between the kernel and > user space. > > Or > > (2) Pass an array of 100 kevent pointers and have to copyout > 4x100 = 400 bytes (representing 400 pointers) between the > kernel and user space. Yes, I agree. However, please note that the numbers aren't quite this good. You have to copy out both the data and flag values to user space, along with the pointer to the structure you chnaged. So this is about 12x100. Also, since the flag/data values are now all over memory, you can't aggregate your calls to copyout(). > I don't know about you, but I'll take #2 any day. And if I have > to keep the original kevent structure I passed to the kernel around, > so what? The cost is virtually nil and I'd probably wind up wasting > the same amount of space (and considerably more code) with my > tracking structures (indexed by the descriptor and filter id, or > by udata) anyway. > > What I want to do is this: > > struct myevent { > struct kevent kev; > ... MY STUFF GOES HERE ... > }; > > Then I want to pass an array of pointers to myevent's to the kernel, > and have it pass an array of pointers of ready events back. Simple, > straightforward, who cares if we are 'wasting' sizeof(struct kevent) > space? The amount of space is zilch compared other things! Okay, I believe we can reach consensus here. What I'll do is essentially keep the current `struct kevent' as it is now. However, a flag will be added to the kqueue() call which establishes the kq, to indicate whether the arrays being passed/returned to kevent() should be pointers to `struct kevent', or the actual structure itself. This will allow exactly what you've outlined above, as well as what I currently have. I understand what you're saying, but I feel more confortable with the copyin/copyout of the structure, it just feels simpler to use, not to mention debug. Anyway, it's 1:30am here, I think I'll sleep on it now. :-) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message