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

[Con Kolivas <kernel@kolivas.org>]

On Fri, 11 Nov 2005 10:13, Christoph Lameter wrote:
> 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.

Great. Thanks for the information, and I prefer to see this patch in on that 
basis.

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

Then I won't alter the when-to-prefetch algorithm.

Thanks!
Con

Attachment: pgp7vXvARW0qx.pgp
Description: PGP signature