From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759859Ab3B0MkM (ORCPT ); Wed, 27 Feb 2013 07:40:12 -0500 Received: from g1t0029.austin.hp.com ([15.216.28.36]:41934 "EHLO g1t0029.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758829Ab3B0MkL (ORCPT ); Wed, 27 Feb 2013 07:40:11 -0500 Message-ID: <512DFEA6.4040403@hp.com> Date: Wed, 27 Feb 2013 07:40:06 -0500 From: Don Morris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Yinghai Lu CC: Andrew Morton , Yasuaki Ishimatsu , Tang Chen , Tim Gardner , "H. Peter Anvin" , Linus Torvalds , Tejun Heo , Tony Luck , Thomas Renninger , linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, a.p.zijlstra@chello.nl, jarkko.sakkinen@intel.com Subject: Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node! References: <512B7D10.4060304@tpi.com> <512B8407.2090807@canonical.com> <512BD753.4080001@hp.com> <512D58C2.1090403@jp.fujitsu.com> <512D7FAD.1040003@jp.fujitsu.com> <512D8EDA.3010602@jp.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/27/2013 12:11 AM, Yinghai Lu wrote: > On Tue, Feb 26, 2013 at 8:43 PM, Yasuaki Ishimatsu > wrote: >> 2013/02/27 13:04, Yinghai Lu wrote: >>> >>> On Tue, Feb 26, 2013 at 7:38 PM, Yasuaki Ishimatsu >>> wrote: >>>> >>>> 2013/02/27 11:30, Yinghai Lu wrote: >>>>> >>>>> Do you mean you can not boot one socket system with 1G ram ? >>>>> Assume socket 0 does not support hotplug, other 31 sockets support hot >>>>> plug. >>>>> >>>>> So we could boot system only with socket0, and later one by one hot >>>>> add other cpus. >>>> >>>> >>>> >>>> In this case, system can boot. But other cpus with bunch of ram hot >>>> plug may fails, since system does not have enough memory for cover >>>> hot added memory. When hot adding memory device, kernel object for the >>>> memory is allocated from 1G ram since hot added memory has not been >>>> enabled. >>>> >>> >>> yes, it may fail, if the one node memory need page table and vmemmap >>> is more than 1g ... >>> >> >>> for hot add memory we need to >>> 1. add another wrapper for init_memory_mapping, just like >>> init_mem_mapping() for booting path. >>> 2. we need make memblock more generic, so we can use it with hot add >>> memory during runtime. >>> 3. with that we can initialize page table for hot added node with ram. >>> a. initial page table for 2M near node top is from node0 ( that does >>> not support hot plug). >>> b. then will use 2M for memory below node top... >>> c. with that we will make sure page table stay on local node. >>> alloc_low_pages need to be updated to support that. >>> 4. need to make sure vmemmap on local node too. >> >> >> I think so too. By this, memory hot plug becomes more useful. >> >>> >>> so hot-remove node will work too later. >>> >>> In the long run, we should make booting path and hot adding more >>> similar and share at most code. >>> That will make code get more test coverage. > > Tang, Yasuaki, Andrew, > > Please check if you are ok with attached reverting patch. > > Tim, Don, > Can you try if attached reverting patch fix all the problems for you ? I'm sure from the discussion on how to leave in memory hotplug it likely won't be just a clean reversion, but as a data point -- yes, this patch does remove the problem as expected (and I don't see any new ones at first glance... though I'm not trying hotplug yet obviously). Thanks, Don Morris