From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBABl-0004Fe-Gy for qemu-devel@nongnu.org; Fri, 12 Dec 2008 10:44:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBABk-0004Ea-MW for qemu-devel@nongnu.org; Fri, 12 Dec 2008 10:44:25 -0500 Received: from [199.232.76.173] (port=38594 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBABk-0004EF-Am for qemu-devel@nongnu.org; Fri, 12 Dec 2008 10:44:24 -0500 Received: from mx2.redhat.com ([66.187.237.31]:33839) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBABj-0005uk-Pr for qemu-devel@nongnu.org; Fri, 12 Dec 2008 10:44:24 -0500 Date: Fri, 12 Dec 2008 16:44:18 +0100 From: Andrea Arcangeli Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool Message-ID: <20081212154418.GM6809@random.random> References: <1228512061-25398-1-git-send-email-aliguori@us.ibm.com> <493E941D.4000608@redhat.com> <493E965E.5050701@us.ibm.com> <20081210164401.GF18814@random.random> <493FFAB6.2000106@codemonkey.ws> <493FFC8E.9080802@redhat.com> <49400F69.8080707@codemonkey.ws> <20081210190810.GG18814@random.random> <20081212142435.GL6809@random.random> <494276CD.6060904@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494276CD.6060904@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Gerd Hoffmann , kvm-devel , qemu-devel@nongnu.org On Fri, Dec 12, 2008 at 08:35:57AM -0600, Anthony Liguori wrote: > I've been thinking about this, the problems I see are: > > 1) It's impossible to accept a file descriptor for a block device (possibly > not a problem) What do you mean with accept? You mean to accept a tcp connection? How would a block device fd be related to accept(2)? > 2) You'd have to open all the file descriptors at once. Otherwise, you get > really strange behavior if the file gets deleted while the guest is running > (for instance, with -snapshot). Definitely, that's what I meant with hack around the bdrv api... not even close to nice but doable in theory. Only advantage is that it runs on older kernels but with seeking I/O lseek has to run as well. Now that linux-aio is out of the picture for quite a long time for us, I guess it worth to wait preadv/pwritev and stick with that and reconsider linux-aio after they fix it... Waiting Gerd to post a full patch. But it's your call... I'm fine either ways. Clearly the os missing preadv/pwritev would need to be limited to 1 thread per fd (but 1 thread per fd kind of breaks with the current _global_ list so I guess they'll be limited to just 1 thread otherwise it may be actually simpler to just open the file multiple times than to have a per-fd queue ;), not the end of the world for them.