Date: Wed, 1 Mar 2006 10:58:44 -0800
From: Paul Jackson <pj@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: clameter@engr.sgi.com, dgc@sgi.com, steiner@sgi.com, Simon.Derr@bull.net,
       linux-kernel@vger.kernel.org, clameter@sgi.com
Subject: Re: [PATCH 01/02] cpuset memory spread slab cache filesys
Message-Id: <20060301105844.d5b243f2.pj@sgi.com>
In-Reply-To: <200603011934.34136.ak@suse.de>
References: <20060227070209.1994.26823.sendpatchset@jackhammer.engr.sgi.com>
	<200602281813.47234.ak@suse.de>
	<20060301102757.f2eec70e.pj@sgi.com>
	<200603011934.34136.ak@suse.de>
Organization: SGI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1113
Lines: 28

Andi wrote:
> The main reason i'm reluctant to use this is that the cpuset fast path
> overhead (e.g. in memory allocators etc.) is quite large

I disagree.

I spent much time minimizing that overhead over the last few months, as
a direct result of your recommendation to do so.

Especially in the case that all tasks are in the root cpuset (as in the
scenario I just suggested for setting this memory spreading policy for
all tasks), the overhead is practically zero.  The key hook is an
inline test done (usually) once per page allocation on an essentially
read only global 'number_of_cpusets' that determines it is <= 1.

I disagree with your "quite large" characterization.

Please explain further.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
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/