Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751247AbWIMX5N (ORCPT ); Wed, 13 Sep 2006 19:57:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751258AbWIMX5N (ORCPT ); Wed, 13 Sep 2006 19:57:13 -0400 Received: from server99.tchmachines.com ([72.9.230.178]:22754 "EHLO server99.tchmachines.com") by vger.kernel.org with ESMTP id S1751247AbWIMX5M (ORCPT ); Wed, 13 Sep 2006 19:57:12 -0400 Date: Wed, 13 Sep 2006 16:59:09 -0700 From: Ravikiran G Thirumalai To: Christoph Lameter Cc: Andrew Morton , linux-kernel@vger.kernel.org, Alok Kataria , "Shai Fultheim (Shai@scalex86.org)" , Christoph Lameter , "Benzi Galili (Benzi@ScaleMP.com)" Subject: Re: [patch] slab: Do not use mempolicy for kmalloc_node Message-ID: <20060913235909.GC4359@localhost.localdomain> References: <20060912144518.GA4653@localhost.localdomain> <20060912195246.GA4039@localhost.localdomain> <20060913221435.GA4359@localhost.localdomain> <20060913233741.GB4359@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server99.tchmachines.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - scalex86.org X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 30 On Wed, Sep 13, 2006 at 04:48:58PM -0700, Christoph Lameter wrote: > On Wed, 13 Sep 2006, Ravikiran G Thirumalai wrote: > > The two cases were your patch still applied memory policies were: > > 1. nodeid = -1. This is one particular case that we wanted to fix because > it means use numa_node_id(). OK, I did not realise nodeid = -1 _should_ imply current node. Not using mempolicy makes sense then. > > 2. The case where the nodelist does not yet exist. > > AFAIK this situation only occurs on boot strap when we are actually > attempting to allocate from a different node than what we are running on. > Falling back to the local node is the right thing to do because we have > that already working. A process that is running on a node must always have > the nodelists for all caches allocated. The cpuup callbacks take care of that. > > kmalloc_node needs work like page_alloc_node. page_alloc_node() never > consults memory policies and thus one would not expect kmalloc_node to do > so either. OK. - 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/