Re: Support concurrent local and remote frees and allocs on a slab.

[Christoph Lameter <clameter@sgi.com>]

On Mon, 7 May 2007, Andrew Morton wrote:

> > I think the major performance improvement was to remove the overhead of 
> > kfree. Half of the effort is gone thus performance goes through the roof. 
> > Also this insures that SLUB always gets no partial slabs which increases 
> > performance further.
> 
> Well sure.  But there should have been a performance *decrease* because
> every piece of memory we get from slab is now cache-cold.  If slab was
> recycling objects, one would expect that to not happen.

No the memory that slub returns is designed to be in increasing memory 
order. The prefetch logic on most modern chips will eliminate the cache 
cold effect.

> So I'm assuming that you have producer and consumer running on separate
> CPUs and we don't get any decent cache reuse anyway.

This was on UP.

> > What is the problem with 21-mm1 btw? slab performance for both allocators 
> > dropped from ~6M/sec to ~4.5M/sec
> 
> That's news to me.  You're the slab guy ;)
> 
> Are you sure the slowdown is due to slab, or did networking break?

Both slab allocators are affected. I poked around but nothing sprang to 
my mind. Seems its networking.
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>