Re: [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory

[Nick Piggin <nickpiggin@yahoo.com.au>]

Rik van Riel wrote:
> Nick Piggin wrote:
> 
>> OK, sure. I think we need more numbers though.
> 
> 
> Thinking about the issue some more, I think I know just the
> number we might want to know.
> 
> It is pretty obvious that the kernel needs to do less work
> with the MADV_FREE code present.  However, it is possible
> that userspace needs to do more work, by accessing pages
> that are not in the CPU cache, or in another CPU's cache.
> 
> In the test cases where you see similar performance on the
> workload with and without the MADV_FREE code, are you by any
> chance seeing lower system time and higher user time?

I didn't actually check system and user times for the mysql
benchmark, but that's exactly what I had in mind when I
mentioned the poor cache behaviour this patch could cause. I
definitely did see user times go up in benchmarks where I
measured.

We have percpu and cache affine page allocators, so when
userspace just frees a page, it is likely to be cache hot, so
we want to free it up so it can be reused by this CPU ASAP.
Likewise, when we newly allocate a page, we want it to be one
that is cache hot on this CPU.


> I think that maybe for 2.6.22 we should just alias MADV_FREE
> to run with the MADV_DONTNEED functionality, so that the glibc
> people can make the change on their side while we figure out
> what will be the best thing to do on the kernel side.
> 
> I'll send in a patch that does that once Linus has committed
> your most recent flood of patches.  What do you think?

I'll let you and Ulrich decide on that. Keep in mind that older
kernels (without the mmap_sem patch for MADV_DONTNEED) still
seem to get a pretty decent improvement from using MADV_DONTNEED,
so it is possible glibc will want to start using that anyway.

-- 
SUSE Labs, Novell Inc.