Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932105AbVKRRUX (ORCPT ); Fri, 18 Nov 2005 12:20:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932287AbVKRRUX (ORCPT ); Fri, 18 Nov 2005 12:20:23 -0500 Received: from omx3-ext.sgi.com ([192.48.171.20]:64677 "EHLO omx3.sgi.com") by vger.kernel.org with ESMTP id S932105AbVKRRUW (ORCPT ); Fri, 18 Nov 2005 12:20:22 -0500 Date: Fri, 18 Nov 2005 09:19:58 -0800 (PST) From: Christoph Lameter To: Andi Kleen cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@osdl.org Subject: Re: [PATCH] NUMA policies in the slab allocator V2 In-Reply-To: <200511180531.47764.ak@suse.de> Message-ID: References: <200511180359.17598.ak@suse.de> <200511180531.47764.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1647 Lines: 41 On Fri, 18 Nov 2005, Andi Kleen wrote: > On Friday 18 November 2005 04:38, Christoph Lameter wrote: > > You really want to run the useless fastpath? Examine lists etc for > > the local node despite the policy telling you to get off node? > > Yes. And this is only the begining of the troubles with such an approach. Lets say you do the fastpath, find that there are no local slab entries available anymore and then consult policy. Policy tells you to interleave so you go to a different node and retrieve a slab entry from the slab list for that node (which is likely not to need to do any page allocation at all). Then this particular request has been fulfilled but there are still no local slab entries. Then the interleave counter may have been incremented without allocating a page. The next request would find no local slab entries available again and repeats the same dysfunctional behavior. But lets say that there is another process running concurrently that uses default policy. It fills up the local slab entry cache. The task running with interleave policy will now start to ignore policy and use the slab entries generated by the page allocation of the other task. Have a look at the slab allocator. I cannot imagine how you could make the approach work. > > Hmm. Is a hugepage ever allocated from interrupt context? > > They aren't. Lets hope that it stays that way... - 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/