Anton wrote:
>> - Don't create caches that are not multiples of L1_CACHE_BYTES.
>
>Nice idea, I often see the list walk (of the cache sizes) in kmalloc in kernel
>profiles. eg a bunch of kmalloc(2k) for network drivers.
>
>Since we have a 128byte cacheline on ppc64 this patch should reduce that.
>
>
No, the patch is a bad thing: It means that everyone who does
kmalloc(32,) now allocates 128 bytes, i.e. 3/4 wasted. IMHO not acceptable.
I agree that the list walk in kmalloc is a problem - but the right
solution is a quicker lookup.
Perhaps something like the attached patch.
For networking: I bet that virtually all allocations have the same size
- what about calling kmem_find_general_cachep, and caching the last
request/result? Then the next calls can allocate directly from the
appropriate cache, without any lookup.
--
Manfred
--- 2.5/mm/slab.c Sat Oct 26 21:13:33 2002 +++ build-2.5/mm/slab.c Sun Oct 27 13:48:06 2002 @@ -424,6 +430,7 @@ CN("size-131072") }; #undef CN +static struct cache_sizes *malloc_hints[sizeof(size_t)*8]; struct arraycache_init initarray_cache __initdata = { { 0, BOOT_CPUCACHE_ENTRIES, 1, 0} }; struct arraycache_init initarray_generic __initdata = { { 0, BOOT_CPUCACHE_ENTRIES, 1, 0} }; @@ -587,6 +594,7 @@ void __init kmem_cache_init(void) { size_t left_over; + int i; init_MUTEX(&cache_chain_sem); INIT_LIST_HEAD(&cache_chain); @@ -604,6 +612,18 @@ * that initializes ac_data for all new cpus */ register_cpu_notifier(&cpucache_notifier); + + for (i=0;i<sizeof(size_t)*8;i++) { + struct cache_sizes *csizep = malloc_sizes; + int size = (1<<i)+1; + + for ( ; csizep->cs_size; csizep++) { + if (size > csizep->cs_size) + continue; + break; + } + malloc_hints[i] = csizep; + } } @@ -1796,7 +1816,11 @@ */ void * kmalloc (size_t size, int flags) { - struct cache_sizes *csizep = malloc_sizes; + struct cache_sizes *csizep; + + if (unlikely(size < 2)) + size = 2; + csizep = malloc_hints[fls((size-1))-1]; for (; csizep->cs_size; csizep++) { if (size > csizep->cs_size)
- 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/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:45 EST