On Mon, 24 Apr 2000, Jamie Lokier wrote:
>
> Even better than picking the cs_cachep: you can inline the allocation &
> the free to very small fast code in cases where it's a per CPU slab (or
> only one SLAB). It's just a matter of pulling something off the free
> list. For ultimate performance, use a ".text.lock" style extra section
> to contain the slow case code ;-)
Be wewy wewy careful. There be dragons here.
In particular, the per-CPU cache has some rather nasty behaviour problems:
you can make up nasty cases where a program is set up to always allocate
on CPU#1, and always free the page on CPU#2. It's fairly hard to trigger
that kind of behaviour from user space, but certainly not impossible.
That said, "get_free_page()" is a very special case of the generic
__get_free_pages(), especially these days that the long-term page
allocations tend to all be done using the other interfaces (that can
do high memory etc and return a page structure pointer instead of a
virtual address).
So it might be much more doable these days to just say "get_free_page()"
is for short-lived allocations, and thus the normal problems with caching
the results are less of an issue. The very fact that the allocation is
short-lived tends to mean that it also balances out much better on average
(ie you won't get unbalanced spikes like you get with allocating and
freeigna whole address space when a process is created and dies on
different CPU's).
We used to have a few "last page" caches, and making them per-CPU would
make them really fast.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:08 EST