[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1204912895.8514.120.camel@twins>
Date: Fri, 07 Mar 2008 19:01:35 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Andrea Arcangeli <andrea@...ranet.com>
Cc: Christoph Lameter <clameter@....com>,
Jack Steiner <steiner@....com>, Nick Piggin <npiggin@...e.de>,
akpm@...ux-foundation.org, Robin Holt <holt@....com>,
Avi Kivity <avi@...ranet.com>, kvm-devel@...ts.sourceforge.net,
general@...ts.openfabrics.org,
Steve Wise <swise@...ngridcomputing.com>,
Roland Dreier <rdreier@...co.com>,
Kanoj Sarcar <kanojsarcar@...oo.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
daniel.blueman@...drics.com
Subject: Re: [PATCH] 3/4 combine RCU with seqlock to allow mmu notifier
methods to sleep (#v9 was 1/4)
On Fri, 2008-03-07 at 18:50 +0100, Andrea Arcangeli wrote:
> Overall my effort is to try to avoid expand the list walk with
> explicit memory barriers like in EMM while trying to be equally
> efficient.
I think we can do with a smb_wmb(); like Christoph (and like
hlist_add_rcu()), but replace the smb_rmb() Christoph has with a
smp_read_barrier_depends().
That should give much the same results.
The reason Christoph can do without RCU is because he doesn't allow
unregister, and as soon as you drop that you'll end up with something
similar.
> Another issue is that the _begin/_end logic doesn't provide any
> guarantee that the _begin will start firing before _end, if a kernel
> module is loaded while another cpu is already running inside some
> munmap operation etc.. The KVM usage of mmu notifier has no problem
> with that detail, but KVM doesn't use _begin at all, I wonder if
> others would have problems. This is a kind of a separate problem, but
> quite related to the question if the notifiers must be guaranteed to
> start firing immediately after mmu_notifier_unregister;synchronize_rcu
> or not, that's why I mentioned it here.
Curious problem indeed. Would it make sense to require registering these
MMU notifiers when the process is still single threaded along with the
requirement that they can never be removed again from a running process?
For KVM this should be quite doable, but I must admit I haven't been
paying enough attention to know if its possible for these other users.
--
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