Date: Fri, 7 Apr 2000 01:09:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jonathan Lemon <jlemon@flugsvamp.com>, Archie Cobbs <archie@whistle.com>, freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code Message-ID: <200004070809.BAA94865@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> <20000407013358.P80578@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> (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().
True enough, but you also save userspace having to do a copy (it
just leaves the structure intact), which saves on the L1 cache
pollution, and the userspace program is somewhat simplified. I
think performance-wise it's either a wash or the pointer method has
a slight edge.
copyin/copyout aren't really all that bad.
Another point: Most systems are fast enough to react to events such
that, typically, not many events queue up before the user process
can get to them. I wouldn't count on the optimization of aggregating
the copyin/copyout.
:> 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
Uff. Well, ok I guess. It will give people a choice and make
performance testing more interesting. I think ultimately people will
opt for convenience - which I think will end up being the pointer method.
We'll see.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200004070809.BAA94865>