Messages in this thread | | | Date | Thu, 01 Apr 2010 19:06:36 +0300 | From | Avi Kivity <> | Subject | Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all_locks() |
| |
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
| |