From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool Date: Fri, 12 Dec 2008 16:44:18 +0100 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 Cc: Gerd Hoffmann , qemu-devel@nongnu.org, kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:41495 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756578AbYLLPoY (ORCPT ); Fri, 12 Dec 2008 10:44:24 -0500 Content-Disposition: inline In-Reply-To: <494276CD.6060904@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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.