|| ||Rik van Riel <riel-AT-redhat.com> |
|| ||Hugh Dickins <hughd-AT-google.com> |
|| ||Re: linux-next: Tree for Nov 14 |
|| ||Wed, 14 Nov 2012 12:05:15 -0500|
|| ||Ingo Molnar <mingo-AT-kernel.org>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Stephen Rothwell <sfr-AT-canb.auug.org.au>,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra-AT-chello.nl>,
Andrea Arcangeli <aarcange-AT-redhat.com>,
Mel Gorman <mgorman-AT-suse.de>|
|| ||Article, Thread
On 11/14/2012 03:13 AM, Hugh Dickins wrote:
> Please, Ingo, stop trying to force this in ahead of time, yet again.
> People are still reviewing and comparing competing solutions.
> Maybe this latest will prove to be closest to the right answer,
> maybe it will not. It's, what, about two days old right now?
> If we had wanted to push in a good solution a little prematurely,
> we would surely have chosen Andrea's AutoNUMA months ago, despite
> efforts to block it; and maybe we shall still want to go that way.
As much as I would like to see NUMA stuff going upstream
the day before yesterday, I have to agree with Hugh that
we need to do things right.
Having unreviewed (some of it NAKed) code sitting in
tip.git and you trying to force it upstream is not the
right way to go.
> Please, forget about v3.8, cut this branch out of linux-next,
> and seek consensus around getting it right for v3.9.
I suspect that no matter how long we delay merging the
NUMA placement code, we will always run into some kind
of regression. I am not sure if a delay will buy us much.
On the mm/ bits, there appears to be consensus already.
Mel Gorman's patch series contains the nicest mm/ bits
from autonuma and sched/numa, plus further improvements.
Andrea has supported Mel's series, and Ingo is pulling
code from it.
That leads me to believe Mel's NUMA bits may be worth
considering for 3.8.
On top of that, we could place the policy code by
Peter and Ingo, but as a nice reviewable patch series,
not hidden away through various tip.git branches.
Does a combination of Mel's NUMA mm/ bits and the
policy code from Peter and Ingo sound reasonable?
Mel, is that reasonable to you?
Peter & Ingo, are you willing to rebase your policy
code on top of Mel's mm/ patches?
All rights reversed
to post comments)