lkml.org 
[lkml]   [2001]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Purpose of the mm/slab.c changes

On Sun, 9 Sep 2001, Alan Cox wrote:
>
> > LIFO is obviously superior due to cache re-use.
>
> Interersting question however. On SMP without sufficient per CPU slab caches
> is tht still the case ?

That _should_ be fairly easily testable by just changing the cpucache
tuning, which yu can do through /proc. The default parameters look
reasonable, though.

Note, however, that as far as the slab is concerned, this issue never
exists, if only because all the lists are per-CPU. So the only way you can
get cross-CPU cache behaviour is (a) when the actual _use_ of the slab is
moved across CPU's and (b) when you have a page that ends up moving from
one CPU to the other through page allocation when the slab caches run out.

Case (a) is clearly rather independent of the actual slab allocation
logic, and depends on the _user_ of the allocation, not on the allocator
itself.

Case (b) implies that the page allocator might also should also find
per-CPU LIFO queues in front of the actual allocator useful. That might
certainly be worth-while looking into - although it would also increase
the risk of fragementation.

(Doing per-CPU LIFO queues for the actual page allocator would potentially
make page alloc/de-alloc much faster due to lower locking requirements
too. So you might have a double performance win if anybody wants to try
this out).

Linus

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

\
 
 \ /
  Last update: 2005-03-22 13:03    [from the cache]
©2003-2011 Jasper Spaans