Re: [RFC] slub: Per object NUMA support

[Christoph Lameter]

On Wed, 11 May 2011, David Rientjes wrote:

> > Anyways the implementation is rather simple.
> >
>
> The implementation may be simple, but it seems like this would absolutely
> kill performance for MPOL_INTERLEAVE if slub is required for every
> kmalloc() or kmem_cache_alloc() to take the alternate slab node's
> list_lock to scan the partial list or, worse yet, allocate a new slab on
> that node when there are objects available on the freelist.

Right. SLAB does something similar though. We could optimize it more by
taking locks like done there and aovid the switching of the per cpu slabs.

> That, to me, would always nullify the performance benefit of using the
> mempolicy in the first place and end up making MPOL_INTERLEAVE worse than
> no mempolicy.  Do you have any benchmarks that suggest this has no
> negative impact?  I'd be very surprised.

The default is no memory policy. You would only use MPOL_INTERLEAVE on
large NUMA system that incur sufficient cross node latency to justify the
interleave.
--
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/