Date: Fri, 7 Apr 2000 01:33:58 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Archie Cobbs <archie@whistle.com>, freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <20000407013358.P80578@prism.flugsvamp.com> In-Reply-To: <200004070547.WAA94276@apollo.backplane.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000407013358.P80578>