From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] qemu-kvm: Switch POSIX compat AIO implementation to upstream Date: Tue, 27 Sep 2011 12:00:46 +0300 Message-ID: <4E8190BE.3000801@redhat.com> References: <4E78C42D.5030207@siemens.com> <20110921080600.GA9847@stefanha-thinkpad.localdomain> <4E80B50B.9000301@siemens.com> <4E80B55F.5020203@redhat.com> <4E80BFF3.8000907@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Stefan Hajnoczi , Marcelo Tosatti , kvm , Kevin Wolf To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31407 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751929Ab1I0JBE (ORCPT ); Tue, 27 Sep 2011 05:01:04 -0400 In-Reply-To: <4E80BFF3.8000907@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/26/2011 09:09 PM, Anthony Liguori wrote: > On 09/26/2011 12:24 PM, Avi Kivity wrote: >> On 09/26/2011 08:23 PM, Jan Kiszka wrote: >>> > >>> > Perhaps qemu_eventfd() can be used in the future instead of an >>> explicit >>> > pipe. Then Linux will do eventfd while other OSes will fall back to >>> > pipes. >>> >>> Basically simpler code, or does this also have runtime benefits? >>> >> >> In corner cases, the completion can block on the write() with pipes, >> but not >> eventfd. > > The pipe is O_NONBLOCK and the only thing the caller cares about is > whether there is *some* data in the PIPE so it can happily ignore EAGAIN. > > So the pipe implementation never blocks on write() either. It may > require multiple reads to drain the queue though whereas eventfd would > only require a single read to drain the queue. > Oh, so switching to eventfd won't change much. Still nice though IMO. -- error compiling committee.c: too many arguments to function