Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [RFC, PATCH] Slab counter troubles with swap prefetch? | Date | Fri, 11 Nov 2005 10:17:43 +1100 |
| |
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 [unhandled content-type:application/pgp-signature] | |