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:	Wed, 14 Nov 2012 00:13:32 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Ingo Molnar <mingo@...nel.org>
cc:	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>, Rik van Riel <riel@...hat.com>
Subject: Re: linux-next: Tree for Nov 14

On Wed, 14 Nov 2012, Ingo Molnar wrote:
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> > On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar <mingo@...nel.org> wrote:
> > > * Andrew Morton <akpm@...ux-foundation.org> wrote:
> > > > On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > > > 
> > > > > News: next-20121115 (i.e. tomorrow) will be the last release until
> > > > > next-20121126 (which should be just be after -rc7, I guess - assuming
> > > > > that Linus does not release v3.7 before then), so if you want something
> > > > > in linux-next for a reasonable amount of testing, it should probably be
> > > > > committed tomorrow.
> > > > 
> > > > It would help if the old sched/numa code wasn't in -next while 
> > > > you're away.  That would give me a clean run at 3.7 and will 
> > > > make it easier for others to integrate and test the four(!) 
> > > > different autoschednumacore implementations on top of 
> > > > linux-next.
> > > > 
> > > > Pretty please?
> > > 
> > > The next integration should have this solved: I have removed the 
> > > old sched/numa bits, replaced by the latest rebased/reworked 
> > > numa/core bits.
> > > 
> > 
> > That solves one problem, but I still need to route around the 
> > numa stuff when preparing the 3.8-rc1 merge.  Again!
> 
> I'm eyeing a v3.8 merge... modulo unforeseen problems. This has 
> been going on for way too long.
> 
> numa/core performs very well, and the rest can be done 
> iteratively.
> 
> The mm/ bits changed very little due to the latest rounds of 
> review. Most of the discussion centered around specific 
> implementational details and naming - and where we were wrong I 
> changed the code - numa/core sums up the consensus so far.
> 
> If I missed anything let me know and I'll fix the code ASAP ...

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.

Please, forget about v3.8, cut this branch out of linux-next,
and seek consensus around getting it right for v3.9.

I dislike speaking out in this way, because I'm well aware of
how very much more effort you and Peter and Andrea and Mel and
Rik and many others are making than I can manage - thank you all.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ