Date: Sat, 4 Feb 2006 20:10:33 -0800
From: Paul Jackson <pj@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: steiner@sgi.com, dgc@sgi.com, Simon.Derr@bull.net, ak@suse.de,
       linux-kernel@vger.kernel.org, clameter@sgi.com
Subject: Re: [PATCH 4/5] cpuset memory spread slab cache optimizations
Message-Id: <20060204201033.5a2200f1.pj@sgi.com>
In-Reply-To: <20060204155038.3191a8c0.akpm@osdl.org>
References: <20060204071910.10021.8437.sendpatchset@jackhammer.engr.sgi.com>
	<20060204071927.10021.75308.sendpatchset@jackhammer.engr.sgi.com>
	<20060204155038.3191a8c0.akpm@osdl.org>
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: 1153
Lines: 31

> We're adding even more goop into the NUMA __cache_alloc() fastpath.  This bad.

Huh?  I'm only adding more goop (beyond a single inline bit test
of current->flags) in the:
	NUMA and (MEMPOLICY or MEM_SPREAD)
path.

>  @@ -2703,20 +2704,9 @@ static inline void *____cache_alloc(stru
> ...
>  +	if (unlikely(current->flags & (PF_MEM_SPREAD|PF_MEMPOLICY)))
>  +		if ((objp = alternate_node_alloc(cachep, flags)) != NULL)
>  +			return objp;

There are three copies of ____cache_alloc() in mm/slab.c, once
compiled.  Do you really want three copies of alternate_node_alloc()
routine in the kernel, just to avoid a subroutine call in the "NUMA and
(MEMPOLICY or MEM_SPREAD)" case?

I doubt you want that.

In other words, I don't understand yet.

-- 
                  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/