Re: [RFC, PATCH] Slab counter troubles with swap prefetch?

From: Christoph Lameter
Date: Thu Nov 10 2005 - 18:13:23 EST


On Fri, 11 Nov 2005, Con Kolivas wrote:

> > This patch splits the counter into the nr_local_slab which reflects
> > slab pages allocated from the local zones (and this number is useful
> > at least as a guidance for the VM) and the remotely allocated pages.
>
> How large a contribution is the remote slab size likely to be? Would this
> information be useful to anyone potentially in future code besides swap
> prefetch? The nature of prefetch is that this is only a fairly coarse measure
> of how full the vm is with data we don't want to displace. Thus it is also
> not important that it is very accurate.

The size of the remote cache depends on many factors. The application can
influence that by setting memory policies.

> Unless the remote slab size can be a very large contribution, or having local

Yes it can be quite large. On some of my tests with applications these are
100%. This is typical if the application sets the policy in such a way
that all allocations are off node or if the kernel has to allocate memory
on a certain node for a device.

> and remote slab sizes is useful potentially to some other code I'm inclined
> to say this is unnecessary. A simple comment saying something like "the
> nr_slab estimation is artificially elevated by remote slab pages on numa,
> however this contribution is not important to the accuracy of this
> algorithm". Of course it is nice to be more accurate and if you think
> worthwhile then we can do this - I'll be happy to be guided by your
> judgement.

> As a side note I doubt any serious size numa hardware will ever be idle enough
> by swap prefetch standards to even start prefetching swap pages. If you think
> hardware of this sort is likely to benefit from swap prefetch then perhaps we
> should look at relaxing the conditions under which prefetching occurs.

Small scale NUMA machines may benefit from swap prefetch but on larger
machines people usually try to avoid swap altogether.

-
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/