Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

[Davide Libenzi <davidel@xmailserver.org>]

On Wed, 4 Jul 2007, Andy Isaacson wrote:

> On Mon, Jul 02, 2007 at 06:55:40PM -0400, Rik van Riel wrote:
> > You could easily replace the cookie with a pointer to a free
> > page pool.
> 
> It just occurred to me that something like this is *required* to get the
> performance benefit from MAP_NOZERO on a busy system.  With Davide's
> current proposal, if there are N jobs with different "nozero cookies"
> busy allocating and deallocating pages on a single-NUMA-node system,
> then there's only a 1/N chance that the page returned by __alloc_pages
> will have the correct cookie, so (N-1)/N percent of the time MAP_NOZERO
> will have no positive effect -- 90% of the time for the case of N=10.

That can indeed happen. If you have a system busy with pressure coming 
from many different users, the recycle efficency goes down proportionally 
with it.
As I said before, I prefer a smaller and less intrusive code that gives 
good recycle efficency for the mejority of systems, WRT the idea of 
dedicated pools.
But maybe I'm wrong, and Rik or you can show up with a patch implementing 
pools that does not hurt code, structure sizes and performances.



> In a mostly unrelated complaint, I note that having a function named
> "alloc_zeroed_page_vma" which returns a potentially nonzero page is, um,
> unintuitive.  It needs a name which does not claim it returns zeroed
> pages.  I'm no good at names, but perhaps "alloc_available_page_vma"?

Yeah, the name "zeroed" is not perfect, but neither it is "available". The 
name should give the idea that the page is either from the same ID/cookie 
or it is zeroed. That naming should be applied back to 
alloc_zeroed_user_highpage(), __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE, ...



- Davide