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

From: Avi Kivity
Date: Thu Apr 01 2010 - 12:07:48 EST

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):

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.

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at