Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755789AbZCJV0o (ORCPT ); Tue, 10 Mar 2009 17:26:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755292AbZCJV0e (ORCPT ); Tue, 10 Mar 2009 17:26:34 -0400 Received: from smtp-out.google.com ([216.239.33.17]:7482 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754225AbZCJV0d (ORCPT ); Tue, 10 Mar 2009 17:26:33 -0400 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=Fyf7Vt+4k6FRn4+ZH+v33rSZ+NIp72QayH92AgS/+A3JmYKgwQD3H6vnCPYy2EKwy 4uTHnb6G5Jc+FVekv0q2w== Date: Tue, 10 Mar 2009 14:24:35 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Christoph Lameter cc: Andrew Morton , Pekka Enberg , Matt Mackall , Paul Menage , Randy Dunlap , KOSAKI Motohiro , linux-kernel@vger.kernel.org Subject: Re: [patch -mm v2] cpusets: add memory_slab_hardwall flag In-Reply-To: Message-ID: References: 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 Content-Length: 1697 Lines: 34 On Tue, 10 Mar 2009, Christoph Lameter wrote: > We already have PF_SPREAD_PAGE PF_SPREAD_SLAB and PF_MEMPOLICY. > PF_MEMPOLICY in slab can have the same role as PF_SLAB_HARDWALL. It > attempts what you describe. One the one hand you duplicate functionality > that is already there and on the other you want to put code in the hot > paths that we have intentionally avoided for ages. > For slab, PF_MEMPOLICY is a viable alternative for the functionality that is being added with this patch. The difference is that it only is enforced when the allocating task is a member of that cpuset and does not require the overhead of scanning the MPOL_BIND zonelist for every allocation to determine whwther a node is acceptable. For slub, there is no current alternative to memory_slab_hardwall. > The description is not accurate. This feature is only useful if someone > comes up with a crummy cpuset definition in which a processor is a member > of multiple cpusets and thus the per cpu queues of multiple subsystems get > objects depending on which cpuset is active. > Cpusets are hierarchical, so it is quite possible that a parent cpuset will include a group of cpus that has affinity to a specific group of mems. This isolates that cpuset and all of its children for NUMA optimiziations. Within that, there can be several descendant cpusets that include disjoint subsets of mems to isolate the memory that can be used for specific jobs. -- 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/