linux-kernel - Re: Benchmark results: "Enhanced NUMA scheduling with adaptive affinity"

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: <50A566FA.2090306@redhat.com>
Date:	Thu, 15 Nov 2012 17:04:42 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Mel Gorman <mgorman@...e.de>, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>, Paul Turner <pjt@...gle.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Christoph Lameter <cl@...ux.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Benchmark results: "Enhanced NUMA scheduling with adaptive affinity"

On 11/15/2012 03:32 PM, Linus Torvalds wrote:
> Ugh.
>
> According to these numbers, the latest sched-numa actually regresses
> against mainline on Specjbb.
>
> No way is this even close to ready for merging in the 3.8 timeframe.
>
> I would ask the invilved people to please come up with a set of
> initial patches that people agree on, so that we can at least start
> merging some of the infrastructure, and see how far we can get on at
> least getting *started*. As I mentioned to Andrew and Mel separately,
> nobody seems to disagree with the TLB optimization patches. What else?
> Is Mel's set of early patches still considered a reasonable starting
> point for everybody?

Mel's infrastructure patches, 1-14 and 17 out
of his latest series, could be a great starting
point.

Ingo is trying to get the mm/ code in his tree
to be mostly the same to Mel's code anyway, so
that is the infrastructure everybody wants.

At that point, we can focus our discussions on
just the policy side, which could help us zoom in
on the issues.

It would also make it possible for us to do apple
to apple comparisons between the various policy
decisions, allowing us to reach a decision based
on data, not just gut feel.

As long as each tree has its own basic infrastructure,
we cannot do apples to apples comparisons; this has
frustrated the discussion for months.

Having all that basic infrastructure upstream should
short-circuit that part of the discussion.

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