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

Davide Libenzi
2007-07-04T23:42:58Z

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