Mark Hemment wrote:
>
> o Ability to add new general size caches on the fly.
> This is coded, but never tested. Again, will probably cause a
> panic/lockup.
> To avoid having to lock the general cache linkage for SMP
> (searched from a kmalloc(), so a lock would be bad), some
> "tricks" are pulled.
>
I don't know if this is a step in the right direction:
If we know the general cache sizes at compile time, we can use
__builtin_constant_p() to optimize fixed kmallocs, and most kmallocs are
fixed size.
On my K6/200, compiled for uniprocessor, the stock
kmalloc(4096,GFP_KERNEL)
is >~ 50% slower compared to a __builtin_constant_p() version.
[kmalloc() + kfree() is 25% slower than fixed_kmalloc() + kfree()]
-- 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 : Thu Jun 15 2000 - 21:00:24 EST