[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100401161551.GE2472@linux.vnet.ibm.com>
Date: Thu, 1 Apr 2010 09:15:51 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Avi Kivity <avi@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org,
Kent Overstreet <kent.overstreet@...il.com>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in
mmu_take_all_locks()
On Thu, Apr 01, 2010 at 07:06:36PM +0300, Avi Kivity wrote:
> 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.
I believe that Peter is referring to the RCU implementation you get
with CONFIG_TREE_PREEMPT_RCU, which currently depends on CONFIG_PREEMPT.
The other implementation is CONFIG_TREE_RCU, which is usually called
"classic RCU".
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists