Re: [PATCH] 3 performance tweaks

From: Manfred Spraul (
Date: Thu May 25 2000 - 13:28:57 EST

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

* 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


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST