Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755423AbZCLRZb (ORCPT ); Thu, 12 Mar 2009 13:25:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754523AbZCLRZW (ORCPT ); Thu, 12 Mar 2009 13:25:22 -0400 Received: from waste.org ([66.93.16.53]:36568 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754827AbZCLRZV (ORCPT ); Thu, 12 Mar 2009 13:25:21 -0400 Subject: Re: [patch -mm] cpusets: add memory_slab_hardwall flag From: Matt Mackall To: Christoph Lameter Cc: David Rientjes , KOSAKI Motohiro , Andrew Morton , Pekka Enberg , Paul Menage , Randy Dunlap , linux-kernel@vger.kernel.org In-Reply-To: References: <20090309123011.A228.A69D9226@jp.fujitsu.com> <20090309181756.CF66.A69D9226@jp.fujitsu.com> <1236719283.3205.24.camel@calx> Content-Type: text/plain Date: Thu, 12 Mar 2009 12:23:24 -0500 Message-Id: <1236878604.3213.57.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: 1391 Lines: 31 On Thu, 2009-03-12 at 12:08 -0400, Christoph Lameter wrote: > On Tue, 10 Mar 2009, Matt Mackall wrote: > > > > > Yes, and that's why we require the cpuset hardwall on a configurable > > > > per-cpuset basis. If a cpuset has set this option for its workload, then > > > > it is demanding object allocations from local memory. Other cpusets that > > > > do not have memory_slab_hardwall set can still allocate from any cpu slab > > > > or partial slab, including those allocated for the hardwall cpuset. > > > > > > You cannot hardwall something that is used in a shared way by processes in > > > multiple cpusets. > > > > He can enforce that every allocation made when a given task is current > > conforms. His patch demonstrates that. > > Of course. But that may just be a subset of the data used by a task. If an > inode, dentry and so on was already allocated in the context of another > process then the locality of that allocation will not be changed. The > hardwall will have no effect. It will if he's also using a namespace. This is part of a larger puzzle. -- 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/