Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all_locks()

[Avi Kivity <avi@redhat.com>]

On 04/01/2010 06:56 PM, Peter Zijlstra wrote:
> On Thu, 2010-04-01 at 18:51 +0300, Avi Kivity wrote:
>    
>> On 04/01/2010 06:42 PM, Andrea Arcangeli wrote:
>>      
>>> On Thu, Apr 01, 2010 at 01:43:14PM +0200, Peter Zijlstra wrote:
>>>
>>>        
>>>> On Thu, 2010-04-01 at 13:27 +0200, Peter Zijlstra wrote:
>>>>
>>>>          
>>>>> I've almost got a patch done that converts those two, still need to look
>>>>> where that tasklist_lock muck happens.
>>>>>
>>>>>            
>>>> OK, so the below builds and boots, only need to track down that
>>>> tasklist_lock nesting, but I got to run an errand first.
>>>>
>>>>          
>>> You should have a look at my old patchset where Christoph already
>>> implemented this (and not for decreasing latency but to allow
>>> scheduling in mmu notifier handlers, only needed by XPMEM):
>>>
>>> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.26-rc7/mmu-notifier-v18/
>>>
>>> The ugliest part of it (that I think you missed below) is the breakage
>>> of the RCU locking in the anon-vma which requires adding refcounting
>>> to it. That was the worst part of the conversion as far as I can tell.
>>>
>>> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.26-rc7/mmu-notifier-v18/anon-vma
>>>
>>>        
>> Can we use srcu now instead?
>>      
> I would much rather we make call_rcu_preempt() available at all times.
>    

I don't understand.  I thought the problem was that the locks were taken 
inside an rcu critical section; switching to srcu would fix that.  But 
how is call_rcu_preempt() related?  Grepping a bit, what is 
call_rcu_preempt()?  my tree doesn't have it.

-- 
error compiling committee.c: too many arguments to function