linux-kernel - Re: linux-next: Tree for Nov 14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50A3CF4B.8020806@redhat.com>
Date:	Wed, 14 Nov 2012 12:05:15 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Hugh Dickins <hughd@...gle.com>
CC:	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Mel Gorman <mgorman@...e.de>
Subject: Re: linux-next: Tree for Nov 14

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 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/