Re: [PATCH 01/02] cpuset memory spread slab cache filesys

[Christoph Lameter]

On Thu, 2 Mar 2006, Andi Kleen wrote:

> (often in my measurements 40% and more of all syscalls are gettimeofday 
> actually)

Yes that is why we excessively optimized gettimeofday in asm on ia64...

> Also we don't have very good balancing control on dcaches.

Right but I hope we will get there if we can get the zoned vm statistics 
in and rework the VM a bit.

> > Please run performance tests with single threaded processes if you 
> > do not believe me before doing any of this.
> 
> Sure. But the motivation is less the single thread performance
> anyways, but more the degradation under extreme loads.

The extreme loads may benefit from interleave. But note that the 
performance gains in the NUMA slab allocator came from exploiting 
locality. The support of policies and other off node memory accesses in 
the SLAB allocator is an afterthought. Only node local accesses can be 
served from per cpu caches with a simple interrupt on / off. Off node 
accesses generated by policies etc will require locking and working with 
remote memory structures.

If these are indeed rare user space accesses that require slab elements 
then these performance issues do not matter and you may be able to spread 
without performance penalties. However, our experience with the slab 
allocator was that intensive workloads can be influenced by slab 
performance.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/