From owner-freebsd-arch Fri Apr 7 1:10: 2 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 1A40437BBF9 for ; Fri, 7 Apr 2000 01:09:40 -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 KAA18753 for ; Fri, 7 Apr 2000 10:13:11 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA35877 for freebsd-arch@freebsd.org; Fri, 7 Apr 2000 10:09:34 +0200 (CEST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 130FD37B8DA for ; Fri, 7 Apr 2000 01:09:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA94865; Fri, 7 Apr 2000 01:09:26 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 Apr 2000 01:09:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200004070809.BAA94865@apollo.backplane.com> To: Jonathan Lemon , Archie Cobbs , freebsd-arch@freebsd.org Subject: Re: RFC: kqueue API and rough code 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> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> (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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message