Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754108AbZCHRCV (ORCPT ); Sun, 8 Mar 2009 13:02:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752714AbZCHRCN (ORCPT ); Sun, 8 Mar 2009 13:02:13 -0400 Received: from waste.org ([66.93.16.53]:59854 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752665AbZCHRCM (ORCPT ); Sun, 8 Mar 2009 13:02:12 -0400 Subject: Re: [patch -mm] cpusets: add memory_slab_hardwall flag From: Matt Mackall To: David Rientjes Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , Paul Menage , Randy Dunlap , linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Date: Sun, 08 Mar 2009 12:01:04 -0500 Message-Id: <1236531664.4192.389.camel@calx> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1376 Lines: 36 On Sun, 2009-03-08 at 09:27 -0700, David Rientjes wrote: > Adds a per-cpuset `memory_slab_hardwall' flag. > > The slab allocator interface for determining whether an object is allowed > is > > int current_cpuset_object_allowed(int node, gfp_t flags) > > This returns non-zero when the object is allowed, either because > current's cpuset does not have memory_slab_hardwall enabled or because > it allows allocation on the node. Otherwise, it returns zero. > > This interface is lockless because a task's cpuset can always be safely > dereferenced atomically. > > For slab, if the physical node id of the cpu cache is not from an > allowable node, the allocation will fail. If an allocation is targeted > for a node that is not allowed, we allocate from an appropriate one > instead of failing. > > For slob, if the page from the slob list is not from an allowable node, > we continue to scan for an appropriate slab. If none can be used, a new > slab is allocated. Looks fine to me, if a little expensive. We'll be needing SLQB support though. -- http://selenic.com : development and support for Mercurial and Linux -- 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/