hi manfred-
did you measure how often a CPU *frees* a cache object allocated by
another CPU? i recall someone saying this doesn't occur frequently --
however, it can be a reliability issue if doing this causes even a small
leak. that might be a good statistic to keep if you don't keep it
already.
On Thu, 8 Jun 2000, Manfred Spraul wrote:
> I've virtually finished my per-cpu slab patch.
>
> http://colorfullife.com/~manfreds/slab/patch-slab-cpu-E
>
> changes since patch -A:
>
> * UP fixed
> * docu updated
> * minor statistics change: c_error from atomic_t to unsigned int
> * fix for the DMA caches, kmalloc(GFP_DMA) works again.
> * smp drain cpu cache moved, kmem_cache_destroy works again.
> * proc_getdata now static
>
> The patch is well tested, please give it a try.
>
> I'm still interested in
>
> * which statistics should I collect about the per-cpu arrays?
> * which realistic benchmarks can I run with a 10 Mbit NE2000 network
> card :-/
> * ideas for further improvements.
>
> If you want to benchmark the code: disable SLAB_DEBUG_SUPPORT &
> SLAB_STATS, otherwise you'll see a huge slowdown: double free detection
> is now always on, and red zoning is also enabled (SLAB_FORCED_DEBUG).
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@bigfoot.com>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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:19 EST