Date:	Wed, 17 Jun 2009 13:28:32 -0400
From:	Gregory Haskins <ghaskins@...ell.com>
To:	Davide Libenzi <davidel@...ilserver.org>
CC:	"Michael S. Tsirkin" <mst@...hat.com>, kvm@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	avi@...hat.com, paulmck@...ux.vnet.ibm.com,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [KVM-RFC PATCH 1/2] eventfd: add an explicit srcu based notifier
 interface

Hi Davide,

Davide Libenzi wrote:
> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>
>   
>> Davide Libenzi wrote:
>>     
>>> On Tue, 16 Jun 2009, Gregory Haskins wrote:
>>>
>>>   
>>>       
>>>> Does this all make sense?
>>>>     
>>>>         
>>> This conversation has been *really* long, and I haven't had time to look 
>>> at the patch yet. But looking at the amount of changes, and the amount of 
>>> even more changes talked in this thread, there's a very slim chance that 
>>> I'll ACK the eventfd code.
>>> You may want to consider a solution that does not litter eventfd code that 
>>> much.
>>>
>>>
>>> - Davide
>>>
>>>
>>>   
>>>       
>> Hi Davide,
>>
>> I understand your position and value your time/insight into looking at
>> this things.
>>
>> Despite the current ongoing discussion, I still stand that the current
>> patch is my proposed solution (though I have yet to convince Michael). 
>> But in any case,  if you have the time, please look it over because I
>> still think its the right direction to head in.
>>     
>
> I don't think so. You basically upload a bunch of stuff it could have been 
> inside your irqfd into eventfd.

Can you elaborate?  I currently do not see how I could do the proposed
concept inside of irqfd while still using eventfd.  Of course, that
would be possible if we fork irqfd from eventfd,  and perhaps this is
what you are proposing.  As previously stated I don't want to give up on
the prospect of re-using it quite yet, so bear with me. :)

The issue with eventfd, as I see it, is that eventfd uses a
spin_lock_irqsave (by virtue of the wait-queue stuff) across the
"signal" callback (which today is implemented as a wake-up).  This
spin_lock implicitly creates a non-preemptible critical section that
occurs independently of whether eventfd_signal() itself is invoked from
a sleepable context or not.

What I strive to achieve is to remove the creation of this internal
critical section.  If eventfd_signal() is called from atomic context, so
be it.  We will detect this in the callback and be forced to take the
slow-path, and I am ok with that.  *But*, if eventfd_signal() (or
f_ops->write(), for that matter) are called from a sleepable context
*and* eventfd doesn't introduce its own critical section (such as with
my srcu patch), we can potentially optimize within the callback by
executing serially instead of deferring (e.g. via a workqueue).

(Note: The issue of changing eventfd_signal interface is a separate
tangent that Michael proposed, and is not something I am advocating.  In
the current proposal, eventfd_signal() retains its exact semantics as it
has in mainline).

>  Now the eventfd_signal() can magically 
> sleep, or not, depending on what the signal functions do. This makes up a 
> pretty aweful interface if you ask me.
> A lot simpler and cleaner if eventfd_signal(), like all the wake up 
> functions inside the kernel, can be called from atomic context. Always, 
> not sometimes.
>   

It can!  :) This is not changing from whats in mainline today (covered
above).

Thanks Davide,
-Greg



Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)

Powered by blists - more mailing lists