From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 0/2] eventfd: new EFD_STATE flag Date: Thu, 20 Aug 2009 19:56:05 +0200 Message-ID: <4A8D8E35.7060606@gnu.org> References: <20090820155655.GA8764@redhat.com> <4A8D8A28.2050004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "Michael S. Tsirkin" , gleb@redhat.com, kvm@vger.kernel.org, Linux Kernel Mailing List To: Davide Libenzi Return-path: Received: from mail-ew0-f207.google.com ([209.85.219.207]:53988 "EHLO mail-ew0-f207.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754585AbZHTR4M (ORCPT ); Thu, 20 Aug 2009 13:56:12 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 08/20/2009 07:44 PM, Davide Libenzi wrote: > On Thu, 20 Aug 2009, Avi Kivity wrote: > >> On 08/20/2009 07:20 PM, Davide Libenzi wrote: >>> >>> I briefly looked at this while in vacation, although I did not reply >>> hoping the horrible feeling about this code would go away. >>> It didn't. >>> I find this to be an ugly and ad-hoc multiplexing of eventfd with added >>> functionalities of questionable general use. >>> I'm pretty sure you can do better on KVM side, to solve the problem w/out >>> littering eventfd. >> >> While we could argue about this my feeling is that we should drop this, at >> least until we can quantify what benefit it has and whether there are any >> Davide-acceptable alternatives. > > I really didn't mean to be harsh, but seriously, we cannot just have a > Multiplexing Feast over eventfd, with one-time users. EFD_STATE actually does two changes: a) makes read block until the value changes; b) makes each write override the previous one. How would you feel if the two changes were separated? I can see each of them has use cases For example, (a) could be implemented by using select's xfds (POLLPRI) to poll for value changes (rfds would still poll for non-zeroness). Then Michael does not need even to read the eventfd; instead he'd check POLLIN with a zero timeout. (b) could be implemented with a flag like Michael did. Paolo