From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBBDD-0007gk-BK for qemu-devel@nongnu.org; Fri, 12 Dec 2008 11:49:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBBDB-0007fM-OQ for qemu-devel@nongnu.org; Fri, 12 Dec 2008 11:49:58 -0500 Received: from [199.232.76.173] (port=33546 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBBDB-0007ez-4m for qemu-devel@nongnu.org; Fri, 12 Dec 2008 11:49:57 -0500 Received: from yw-out-1718.google.com ([74.125.46.158]:58965) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBBDA-0006JE-MQ for qemu-devel@nongnu.org; Fri, 12 Dec 2008 11:49:56 -0500 Received: by yw-out-1718.google.com with SMTP id 6so700399ywa.82 for ; Fri, 12 Dec 2008 08:49:55 -0800 (PST) Message-ID: <49429629.20309@codemonkey.ws> Date: Fri, 12 Dec 2008 10:49:45 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool 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> In-Reply-To: <20081212154418.GM6809@random.random> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: Gerd Hoffmann , kvm-devel , qemu-devel@nongnu.org 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