Message-Id: <20130227132612.14664a3a.akpm@linux-foundation.org>
Date:	Wed, 27 Feb 2013 13:26:12 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Tang Chen <tangchen@...fujitsu.com>,
	Don Morris <don.morris@...com>,
	Tim Gardner <tim.gardner@...onical.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Tony Luck <tony.luck@...el.com>,
	Thomas Renninger <trenn@...e.de>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...hat.com, a.p.zijlstra@...llo.nl,
	jarkko.sakkinen@...el.com
Subject: Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

On Wed, 27 Feb 2013 16:00:36 +0800
Lai Jiangshan <laijs@...fujitsu.com> wrote:

> In the mails and the changlog of the revert-patch, I think Yinghai
> mainly worries about 3 problems.
> 
> 1) the current implement has bug and bad code.
> 
> 	Yes. Any bug should be fixed. we should fix it directly, or
> 	we can revert the related patches and then send the fixed patches.
> 
> 	But the related patch is only one or two, it is not good idea
> 	to revert the whole patchset or the whole feature. Right?

Reverting a new patchset isn't really a big deal.  The patchset gets
fixed up, retested then reapplied.  We like to do things this way
because it minimises the amount of trouble which the regression is
causing other people.

Reverting one or two patches from a fairly large and complex patchset
sounds risky - we're putting an untested patch combination straight
into mainline with minimal testing.  It would be safer to revert
everything.

So I'm thinking that the best approach here is to revert everything and
then try again for 3.10-rc1.  This gives people time to test the code
while it's only in linux-next.  (Hint!)

> 	Thank you all for addressing the bug. we are on the way to fix it.

How long do you think this will take?

> 2) many memory can be put into hotplugable memory, but we have not yet moved them
>    into hotplugable memory yet. like: vmemmap, some page table ...etc, a lot.
> 
> 	This is a restriction in the currently kernel, we can't convert them quickly.
> 	we must convert them step by step. example, we are converting the memory of
> 	page_cgroup to hotplugable memory.
> 
> 
> 3) if the user(or firmware) specify the un-hotplugable memory too small, the system can't
>    work, even can't boot.
> 
> 	Any feature/system has its own minimum requirements, the user should
> 	meet the requirements and specify more un-hotplugable memory.
> 	so I don't think it is a problem in kernel land.
> 
> 	But the problem 2)(above) make this feature's "minimum requirements"
> 	much higher. It is the real thing that Yinghai worries about.
> 
> 	But all systems which use this feature can offer this higher requirement
> 	very easily. The users should specify enough un-hotplugable memory
> 	before and after we decrease the "minimum requirements".
> 
> 	The whole feature works very well if the user specify enough
> 	un-hotplugable memory. So the problem 2) and 3) are not urgent
> 	problems.

Yes, let's not mingle concepts.  From a feature perspective we've
always understood that 3.9 memory hotplug would be "has limitations,
needs work, but better than it was before".  Let's consider that
separately from "your patchset broke my kernel".

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