Message-Id: <20070403125903.3e8577f4.akpm@linux-foundation.org>
Date:	Tue, 3 Apr 2007 12:59:03 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Ulrich Drepper <drepper@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Jakub Jelinek <jakub@...hat.com>, linux-mm@...ck.org,
	Hugh Dickins <hugh@...itas.com>
Subject: Re: missing madvise functionality

On Tue, 3 Apr 2007 19:28:41 +0200
Andi Kleen <andi@...stfloor.org> wrote:

> On Tue, Apr 03, 2007 at 10:20:02AM -0700, Ulrich Drepper wrote:
> > Andi Kleen wrote:
> > > Why do you need a lock for that? I don't see any problem with
> > > two threads doing that in parallel. The kernel would
> > > serialize it internally and one would fail, but that shouldn't
> > > be a problem. 
> > 
> > There is no lock at all at userlevel.  I'm talking about locks in the
> > kernel.
> 
> mmap_sem? Your new operation wouldn't solve that neither.

It might, a bit.  Both mmap() and mprotect() currently take mmap_sem() for
writing.  If we're careful, we could probably arrange for MADV_ULRICH to
take it for reading, which will help a little bit, hopefully.

It's a little sad that mprotect() takes mmap_sem for writing, really.  I think
the only reason for doing that is because we might do a vma_merge() as a
result.  Perhaps this is on the wrong side of the speed/space tradeoff.

otoh, converting a down_write() to a down_read() may well not have much
effect.

Ulrich, could you suggest a little test app which would demonstrate this
behaviour?

> There were some proposals to fix mmap_sem (it's a big issue
> for futexes too) but they're are quite involved.

yup.

Question:

>   - if an access to a page in the range happens in the future it must
>     succeed.  The old page content can be provided or a new, empty page
>    can be provided

How important is this "use the old page if it is available" feature?  If we
were to simply implement a fast unconditional-free-the-page, so that
subsequent accesses always returned a new, zeroed page, do we expect that
this will be a 90%-good-enough thing, or will it be significantly
inefficient?


If we do implement this retain-the-old-page-if-possible feature, I'm
thinking that we can possibly reuse swapcache concepts.  Such a page is
very similar to a clean, unmapped swapcache page, only it doesn't actually
have a swap mapping (well, it might have a swap mapping, in which case we
don't need to do anything at all, except deactivate it).

So perhaps we can do something like chop swapper_space in half: the lower
50% represent offsets which have a swap mapping and the upper 50% are fake
swapcache pages which don't actually consume swapspace.  These pages are
unmapped from pagetables, marked clean, added to the fake part of
swapper_space and are deactivated.  Teach the low-level swap code to ignore
the request to free physical swapspace when these pages are released.

Or, if that's all too hacky, create a new address_space for these pages and
burn a new page flag.  But I suspect we'd end up duplicating so much
swapcache handling that this will end up looking silly.

This would all halve the maximum amount of swap which can be used.  iirc
i386 supports 27 bits of swapcache indexing, and 26 bits is 274GB, which
is hopefully enough..

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists