Thread (21 messages) 21 messages, 10 authors, 2012-11-15

Re: linux-next: Tree for Nov 14

From: Ingo Molnar <mingo@kernel.org>
Date: 2012-11-14 07:39:36
Also in: lkml

* Andrew Morton [off-list ref] wrote:
On Wed, 14 Nov 2012 07:47:26 +0100 Ingo Molnar [off-list ref] wrote:
quoted
* Andrew Morton [off-list ref] wrote:
quoted
On Wed, 14 Nov 2012 16:30:42 +1100 Stephen Rothwell [off-list ref] wrote:
quoted
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 ...

Thanks,

	Ingo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help