Mark Hemment wrote:
>
> Some of my goals are;
Some more ideas:
* Optimization for slabs with only one object per slab:
drop the slab, drop the bufctl. There is zero fragmentation, so a simple
linked list stored in "struct page" will be faster than the bufctl
approach, without any disadvantages.
* I don't like the flush daemon: The f_limit should protect us from
really bad cases, and we can set it to 0 for rarely needed caches.
* I consider smp_call_function() during kmem_cache_reap(): On my dual
PII/350, it costs 1600 cpu ticks [equivalent of 80 locked instructions],
and one call could flush all per-cpu lists.
* Add a special flags for "no per-cpu cache": I would set the per-cpu
list length to 0 for objects > PAGE_SIZE: they are rare, and too
expensive.
* Is there a special reason why you implement multiple strategies for
finding the slabp during kfree()? What about always using a pointer in
"struct page"?
Mispredicted branches are very expensive: IIRC Intel mentions 10-15 cpu
ticks and that cost will rise [IIRC 20 pipeline stages in the next Intel
Pentium].
-- Manfred- 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 : Wed May 31 2000 - 21:00:14 EST