Messages in this thread |  | | Date | Sun, 9 Sep 2001 10:01:32 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 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/
|  |