From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8Yv3-00043h-My for qemu-devel@nongnu.org; Tue, 27 Sep 2011 10:46:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8Yuy-0006FK-0Z for qemu-devel@nongnu.org; Tue, 27 Sep 2011 10:46:01 -0400 Received: from goliath.siemens.de ([192.35.17.28]:21882) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8Yux-0006Er-I9 for qemu-devel@nongnu.org; Tue, 27 Sep 2011 10:45:55 -0400 Message-ID: <4E81E18C.2000906@siemens.com> Date: Tue, 27 Sep 2011 16:45:32 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E78C42D.5030207@siemens.com> <20110921080600.GA9847@stefanha-thinkpad.localdomain> <4E80B50B.9000301@siemens.com> <4E80B55F.5020203@redhat.com> <4E80BFF3.8000907@us.ibm.com> <4E8190BE.3000801@redhat.com> <4E81D609.1060203@siemens.com> <4E81D88B.4020504@codemonkey.ws> <4E81DDDF.8050201@siemens.com> <4E81DEEA.10208@redhat.com> <4E81DF7C.4080403@siemens.com> <4E81E0C9.7030702@redhat.com> In-Reply-To: <4E81E0C9.7030702@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Use qemu_eventfd for POSIX AIO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel On 2011-09-27 16:42, Avi Kivity wrote: > On 09/27/2011 05:36 PM, Jan Kiszka wrote: >> On 2011-09-27 16:34, Avi Kivity wrote: >>> On 09/27/2011 05:29 PM, Jan Kiszka wrote: >>>>> >>>>> Moreover, the eventfd() counter is not lossy (practically speaking) whereas if >>>>> you use pipe() as a counter, it will be lossy in practice. >>>>> >>>>> This is why posix aio uses pipe() and not eventfd(). >>>> >>>> I don't get this yet. eventfd is lossy by default. It only decreases the >>>> counter on read if you specify EFD_SEMAPHORE - which we do not do. >>>> >>> >>> It's not lossy - a read returns the number of events written since the >>> last read. >> >> Yeah, but what's the point? We don't evaluate this. >> >> > > If we write an interface that looks like eventfd but subtly differs, > someone will get bitten. If we write a new interface and implement it > via eventfd (or a pipe), no one gets bitten. I don't disagree that there is still room for improving the existing interface, generalizing to qemu_event. But that's not in the scope of this patch. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux