From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752084Ab0CBVDN (ORCPT ); Tue, 2 Mar 2010 16:03:13 -0500 Received: from smtp-out.google.com ([216.239.44.51]:16961 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750797Ab0CBVDL (ORCPT ); Tue, 2 Mar 2010 16:03:11 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=ouWVDsia/a9t+0lGWCh/DrW69KiqKwwXGoIh3XsLLxcOA48OZPphLSb6JRLJkaIut +Q8tVeXSwShSCVyydnUJg== Date: Tue, 2 Mar 2010 13:03:01 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Christoph Lameter cc: Pekka Enberg , Andi Kleen , Nick Piggin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, haicheng.li@intel.com, KAMEZAWA Hiroyuki Subject: Re: [patch] slab: add memory hotplug support In-Reply-To: Message-ID: References: <20100215105253.GE21783@one.firstfloor.org> <20100215110135.GN5723@laptop> <20100220090154.GB11287@basil.fritz.box> <4B862623.5090608@cs.helsinki.fi> <20100226114136.GA16335@basil.fritz.box> <20100226155755.GE16335@basil.fritz.box> <4B8CA7F5.1030802@cs.helsinki.fi> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Mar 2010, Christoph Lameter wrote: > > Not sure how this would sync with slab use during node bootstrap and > shutdown. Kame-san? > All the nodelist allocation and initialization is done during MEM_GOING_ONLINE, so there should be no use of them until that notification cycle is done and it has graduated to MEM_ONLINE: if there are, there're even bigger problems because zonelist haven't even been built for that pgdat yet. I can only speculate, but since Andi's patchset did all this during MEM_ONLINE, where the bit is already set in node_states[N_HIGH_MEMORY] and is passable to kmalloc_node(), this is probably why additional hacks had to be added elsewhere. Other than that, concurrent kmem_cache_create() is protected by cache_chain_mutex. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 452C16B0047 for ; Tue, 2 Mar 2010 16:03:13 -0500 (EST) Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id o22L38IT005940 for ; Tue, 2 Mar 2010 13:03:11 -0800 Received: from pvc7 (pvc7.prod.google.com [10.241.209.135]) by spaceape24.eur.corp.google.com with ESMTP id o22L36kS029938 for ; Tue, 2 Mar 2010 13:03:07 -0800 Received: by pvc7 with SMTP id 7so190956pvc.21 for ; Tue, 02 Mar 2010 13:03:06 -0800 (PST) Date: Tue, 2 Mar 2010 13:03:01 -0800 (PST) From: David Rientjes Subject: Re: [patch] slab: add memory hotplug support In-Reply-To: Message-ID: References: <20100215105253.GE21783@one.firstfloor.org> <20100215110135.GN5723@laptop> <20100220090154.GB11287@basil.fritz.box> <4B862623.5090608@cs.helsinki.fi> <20100226114136.GA16335@basil.fritz.box> <20100226155755.GE16335@basil.fritz.box> <4B8CA7F5.1030802@cs.helsinki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: Pekka Enberg , Andi Kleen , Nick Piggin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, haicheng.li@intel.com, KAMEZAWA Hiroyuki List-ID: On Tue, 2 Mar 2010, Christoph Lameter wrote: > > Not sure how this would sync with slab use during node bootstrap and > shutdown. Kame-san? > All the nodelist allocation and initialization is done during MEM_GOING_ONLINE, so there should be no use of them until that notification cycle is done and it has graduated to MEM_ONLINE: if there are, there're even bigger problems because zonelist haven't even been built for that pgdat yet. I can only speculate, but since Andi's patchset did all this during MEM_ONLINE, where the bit is already set in node_states[N_HIGH_MEMORY] and is passable to kmalloc_node(), this is probably why additional hacks had to be added elsewhere. Other than that, concurrent kmem_cache_create() is protected by cache_chain_mutex. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org