[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080402142609.GD22493@sgi.com>
Date: Wed, 2 Apr 2008 09:26:10 -0500
From: Robin Holt <holt@....com>
To: Andrea Arcangeli <andrea@...ranet.com>
Cc: Robin Holt <holt@....com>, Christoph Lameter <clameter@....com>,
Hugh Dickins <hugh@...itas.com>, Avi Kivity <avi@...ranet.com>,
Izik Eidus <izike@...ranet.com>,
kvm-devel@...ts.sourceforge.net,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
general@...ts.openfabrics.org,
Steve Wise <swise@...ngridcomputing.com>,
Roland Dreier <rdreier@...co.com>,
Kanoj Sarcar <kanojsarcar@...oo.com>, steiner@....com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
daniel.blueman@...drics.com, Nick Piggin <npiggin@...e.de>
Subject: Re: [patch 1/9] EMM Notifier: The notifier calls
I must have missed v10. Could you repost so I can build xpmem
against it to see how it operates? To help reduce confusion, you should
probably comandeer the patches from Christoph's set which you think are
needed to make it sleep.
Thanks,
Robin
On Wed, Apr 02, 2008 at 01:16:51PM +0200, Andrea Arcangeli wrote:
> On Wed, Apr 02, 2008 at 05:59:25AM -0500, Robin Holt wrote:
> > On Wed, Apr 02, 2008 at 08:49:52AM +0200, Andrea Arcangeli wrote:
> > > Most other patches will apply cleanly on top of my coming mmu
> > > notifiers #v10 that I hope will go in -mm.
> > >
> > > For #v10 the only two left open issues to discuss are:
> >
> > Does your v10 allow sleeping inside the callbacks?
>
> Yes if you apply all the patches. But not if you apply the first patch
> only, most patches in EMM serie will apply cleanly or with minor
> rejects to #v10 too, Christoph's further work to make EEM sleep
> capable looks very good and it's going to be 100% shared, it's also
> going to be a lot more controversial for merging than the two #v10 or
> EMM first patch. EMM also doesn't allow sleeping inside the callbacks
> if you only apply the first patch in the serie.
>
> My priority is to get #v9 or the coming #v10 merged in -mm (only
> difference will be the replacement of rcu_read_lock with the seqlock
> to avoid breaking the synchronize_rcu in GRU code). I will mix seqlock
> with rcu ordered writes. EMM indeed breaks GRU by making
> synchronize_rcu a noop and by not providing any alternative (I will
> obsolete synchronize_rcu making it a noop instead). This assumes Jack
> used synchronize_rcu for whatever good reason. But this isn't the real
> strong point against EMM, adding seqlock to EMM is as easy as adding
> it to #v10 (admittedly with #v10 is a bit easier because I didn't
> expand the hlist operations for zero gain like in EMM).
> --
> 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/
--
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