From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool Date: Fri, 12 Dec 2008 10:49:45 -0600 Message-ID: <49429629.20309@codemonkey.ws> 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> <20081212154418.GM6809@random.random> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerd Hoffmann , qemu-devel@nongnu.org, kvm-devel To: Andrea Arcangeli Return-path: Received: from an-out-0708.google.com ([209.85.132.250]:35627 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759590AbYLLQt5 (ORCPT ); Fri, 12 Dec 2008 11:49:57 -0500 Received: by an-out-0708.google.com with SMTP id d40so707081and.1 for ; Fri, 12 Dec 2008 08:49:55 -0800 (PST) In-Reply-To: <20081212154418.GM6809@random.random> Sender: kvm-owner@vger.kernel.org List-ID: Andrea Arcangeli wrote: > 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)? > I meant, if you wanted to pass a file descriptor as a raw device. So: qemu -hda raw:fd=4 Or something like that. We don't support this today. > 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. > I think bouncing the iov and just using pread/pwrite may be our best bet. It means memory allocation but we can cap it. Since we're using threads, we just can force a thread to sleep until memory becomes available so it's actually pretty straight forward. We can use libaio on older Linux's to simulate preadv/pwritev. Use the proper syscalls on newer kernels, on BSDs, and bounce everything else. Regards, Anthony Liguori