Re: [Patch 3/3] prepopulate/cache cleared pages

From: Pavel Machek
Date: Tue Feb 28 2006 - 17:29:42 EST


On Ät 23-02-06 13:41:53, Ingo Molnar wrote:
>
> * Andi Kleen <ak@xxxxxxx> wrote:
>
> > On Thursday 23 February 2006 10:29, Arjan van de Ven wrote:
> > > This patch adds an entry for a cleared page to the task struct. The main
> > > purpose of this patch is to be able to pre-allocate and clear a page in a
> > > pagefault scenario before taking any locks (esp mmap_sem),
> > > opportunistically. Allocating+clearing a page is an very expensive
> > > operation that currently increases lock hold times quite bit (in a threaded
> > > environment that allocates/use/frees memory on a regular basis, this leads
> > > to contention).
> > >
> > > This is probably the most controversial patch of the 3, since there is
> > > a potential to take up 1 page per thread in this cache. In practice it's
> > > not as bad as it sounds (a large degree of the pagefaults are anonymous
> > > and thus immediately use up the page). One could argue "let the VM reap
> > > these" but that has a few downsides; it increases locking needs but more,
> > > clearing a page is relatively expensive, if the VM reaps the page again
> > > in case it wasn't needed, the work was just wasted.
> >
> > Looks like an incredible bad hack. What workload was that again where
> > it helps? And how much? I think before we can consider adding that
> > ugly code you would a far better rationale.
>
> yes, the patch is controversial technologically, and Arjan pointed it
> out above. This is nothing new - and Arjan probably submitted this to
> lkml so that he can get contructive feedback.

Actually, I think I have to back Andi here. This looked like patch for
inclusion (signed-off, cc-ed Andrew). And yes, Arjan pointed out that
it is controversial, but the way patch was worded I could imagine
Andrew merging it...
Pavel
--
Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/