Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753241AbZGBX5z (ORCPT ); Thu, 2 Jul 2009 19:57:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753530AbZGBX5r (ORCPT ); Thu, 2 Jul 2009 19:57:47 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:60133 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752861AbZGBX5q (ORCPT ); Thu, 2 Jul 2009 19:57:46 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Fri, 3 Jul 2009 08:55:56 +0900 From: KAMEZAWA Hiroyuki To: Christoph Lameter Cc: Yasunori Goto , yakui , "Li, Shaohua" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "mel@csn.ul.ie" Subject: Re: + memory-hotplug-alloc-page-from-other-node-in-memory-online.patch added to -mm tree Message-Id: <20090703085556.fc711310.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <1246497073.18688.28.camel@localhost.localdomain> <20090702102208.ff480a2d.kamezawa.hiroyu@jp.fujitsu.com> <20090702144415.8B21.E1E9C6FF@jp.fujitsu.com> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1941 Lines: 53 On Thu, 2 Jul 2009 09:31:04 -0400 (EDT) Christoph Lameter wrote: > On Thu, 2 Jul 2009, Yasunori Goto wrote: > > > However, I don't enough time for memory hotplug now, > > and they are just redundant functions now. > > If someone create new allocator (and unifying bootmem allocator), > > I'm very glad. :-) > > "Senior"ities all around.... A move like that would require serious > commitment of time. None of us older developers can take that on it > seems. > > Do we need to accept that the zone and page metadata are living on another > node? > I don't think so. Someone should do. I just think I can't do it _now_. (because I have more things to do for cgroup..) And, if not node-hotplug, memmap is allocated from local memory if possible. "We should _never_ allow fallback to other nodes or not" is problem ? I think we should allow fallback. About pgdat, zones, I hope they will be on-cache... Maybe followings are necessary for allocating pgdat/zones from local node at node-hotplug. a) Add new tiny functions to alloacate memory from not-initialized area. allocate pgdat/memmap from here if necessary. b) leave allocated memory from (a) as PG_reserved at onlining. c) There will be "not unpluggable" section after (b). We should show this to users. d) For removal, we have to keep precise trace of PG_reserved pages. e) vmemmap removal, which uses large page for vmemmap, is a problem. edges of section memmap is not aligned to large pages. Then we need some clever trick to handle this. Allocationg memmap from its own section was an idea (I love this) but IBM's 16MB memory section doesn't allow this. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/