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

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

Hi Christoph

On Fri, 11 Nov 2005 08:55, Christoph Lameter wrote:
> Currently the slab allocator uses a page_state counter called nr_slab.
> The VM swap prefetch code assumes that this describes the number of pages
> used on a node by the slab allocator. However, that is not really true.
>
> Currently nr_slab is the number of total pages allocated which may
> be local or remote pages. Remote allocations may artificially inflate
> nr_slab and therefore disable swap prefetching.

Thanks for pointing this out.

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

Unless the remote slab size can be a very large contribution, or having local 
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.

Cheers,
Con

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]