linux-kernel - Re: [RFC PATCH 00/31] Foundation for automatic NUMA balancing V2

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]

Date:	Tue, 13 Nov 2012 16:14:16 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 00/31] Foundation for automatic NUMA balancing V2

* Mel Gorman <mgorman@...e.de> wrote:

> (Since I wrote this changelog there has been another release 
> of schednuma. I had delayed releasing this series long enough 
> and decided not to delay further. Of course, I plan to dig 
> into that new revision and see what has changed.)

Thanks, I've picked up a number of cleanups from your series and 
propagated them into tip:numa/core tree.

FYI, in addition to the specific patches to which I replied to 
earier today, I've also propagated all your:

   CONFIG_SCHED_NUMA -> CONFIG_BALANCE_NUMA

renames thoughout the patches - I fundamentally agree that 
CONFIG_BALANCE_NUMA is a better, more generic name.

My structural criticism of the architecture specific bits of 
your patch-queue still applies to this version as well. That 
change inflicted much of the changes that you had to do to 
Peter's patches. It blew up the size of your tree and forks the 
code into per architecture variants for no good reason.

Had you not done that and had you kept the code generic you'd 
essentially end up close to where tip:numa/core is today.

So if we can clear that core issue up we'll have quite a bit of 
agreement.

I'd also like to add another, structural side note: you mixed 
new vm-stats bits into the whole queue, needlessly blowing up 
the size and the mm/ specific portions of the tree. I'd suggest 
to post and keep those bits separately, preferably on top of 
what we have already once it has settled down. I'm keeping the 
'perf bench numa' bits separate as well.

Anyway, I've applied all applicable cleanups from you and picked 
up Peter's latest code with the modifications I've indicated in 
that thread, to the latest tip:numa/core tree, which I'll send 
out for review in the next hour or so.

This version is supposed to address all review feedback received 
so far: it refines the MM specific split-up of the patches, 
fixes regressions - see the changelogs for more details.

I'll (re-)send the full series of the latest patches and any 
additional feedback will be welcome.

Thanks,

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