From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53473) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SubqA-0000LW-7T for qemu-devel@nongnu.org; Fri, 27 Jul 2012 00:07:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Subq6-0001cW-29 for qemu-devel@nongnu.org; Fri, 27 Jul 2012 00:07:50 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:53999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Subq5-0001cN-RO for qemu-devel@nongnu.org; Fri, 27 Jul 2012 00:07:45 -0400 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Jul 2012 22:07:44 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 802463E4003C for ; Fri, 27 Jul 2012 04:07:40 +0000 (WET) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6R47ead168726 for ; Thu, 26 Jul 2012 22:07:40 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6R47eYr000988 for ; Thu, 26 Jul 2012 22:07:40 -0600 Message-ID: <5012140A.9040503@linux.vnet.ibm.com> Date: Fri, 27 Jul 2012 00:07:38 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1343048885-1701-1-git-send-email-coreyb@linux.vnet.ibm.com> <1343048885-1701-7-git-send-email-coreyb@linux.vnet.ibm.com> <500E901D.3080801@redhat.com> <500F6B04.4020508@linux.vnet.ibm.com> <500FACD6.700@redhat.com> <50104826.1040909@redhat.com> <5010B7D3.6090309@linux.vnet.ibm.com> <5011425E.8030201@redhat.com> <50114333.7090209@redhat.com> In-Reply-To: <50114333.7090209@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 6/6] block: Enable qemu_open/close to work with fd sets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, Eric Blake On 07/26/2012 09:16 AM, Kevin Wolf wrote: > Am 26.07.2012 15:13, schrieb Eric Blake: >> On 07/25/2012 09:21 PM, Corey Bryant wrote: >>> >>> >>> On 07/25/2012 03:25 PM, Eric Blake wrote: >>>> On 07/25/2012 02:22 AM, Kevin Wolf wrote: >>>>>>> Hm, not a nice interface where qemu_close() needs the filename and >>>>>>> (worse) could be given a wrong filename. Maybe it would be better to >>>>>>> maintain a list of fd -> fdset mappings in qemu_open/close? >>>>>>> >>>>>> >>>>>> I agree, I don't really like it either. >>>>>> >>>>>> We already have a list of fd -> fdset mappings (mon_fdset_fd_t -> >>>>>> mon_fdset_t). Would it be too costly to loop through all the >>>>>> fdsets/fds >>>>>> at the beginning of every qemu_close()? >>>>> >>>>> I don't think so. qemu_close() is not a fast path and happens almost >>>>> never, and the list is short enough that searching it isn't a problem >>>>> anyway. >>>> >>>> I agree - just do the loop to do the reverse lookup yourself, rather >>>> than making qemu_close() have a different signature than close(). >>>> >>> >>> Great, I'll do this then. >> >> You may want an optimization of using a bitset for tracking which fds >> are tracked by fdset in the first place, so that the fast path of >> qemu_close() will be a check against the bitset to see if you even have >> to waste time on the reverse lookup in the first place. The bitset will >> typically be small (bounded not only by the maximum possible fd, but >> further by the fact that we don't usually open that many fds in the >> first place), but I'm not sure if you can get away with static sizing. > > Premature optimisation, in my opinion. The list is really small. > > Kevin > I'll probably hold off on any optimisation at this point, but I can revisit it in the future if it's needed. -- Regards, Corey