[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Page table sharing
- To: Linus Torvalds <torvalds@transmeta.com>
- Subject: Re: [RFC] Page table sharing
- From: Daniel Phillips <phillips@bonn-fries.net>
- Date: Tue, 19 Feb 2002 03:12:28 +0100
- Cc: Hugh Dickins <hugh@veritas.com>, <dmccr@us.ibm.com>,Kernel Mailing List <linux-kernel@vger.kernel.org>,<linux-mm@kvack.org>, Robert Love <rml@tech9.net>,Rik van Riel <riel@conectiva.com.br>, <mingo@redhat.com>,Andrew Morton <akpm@zip.com.au>, <manfred@colorfullife.com>,<wli@holomorphy.com>
- Fake-Sender: owner-linux-mm@kvack.org
- In-Reply-To: <Pine.LNX.4.33.0202181749110.24597-100000@home.transmeta.com>
- Original-Recipient: rfc822;linux-mm-archive@humbolt.geo.uu.nl
- References: <Pine.LNX.4.33.0202181749110.24597-100000@home.transmeta.com>
- Sender: Rik van Riel <riel@nl.linux.org>
On February 19, 2002 02:53 am, Linus Torvalds wrote:
> On Tue, 19 Feb 2002, Daniel Phillips wrote:
> >
> > Somebody might read fault, changing an entry when we're in the middle of
> > copying it and might might do a duplicated read fault.
>
> You're confusing the mm->mmap_sem with the page_table_lock.
>
> The mm semaphore is really a read-write semaphore, and yes, there can be
> multiple faulters active at the same time readin gin pages.
>
> But the page_table_lock is 100% exclusive, and while you hold the
> page_table_lock there is absolutely _not_ going to be any concurrent page
> faulting.
Sure there can be, because we only hold the mm->page_table_lock for this,
somebody could be faulting through another mm sharing the page table. For
this reason I believe I have to look at the page table count, and unless
it's one, I have to do some extra exclusion.
> (NOTE! Sure, there might be another mm that has the same pmd shared, but
> that one is going to do an unshare before it actually touches anything in
> the pmd, so it's NOT going to change the values in the original pmd).
Actually, I was planning to keep the tables shared, even through swapin/
swapout. The data remains valid for all mm's, whether it's in ram or in
swap.
> So I'm personally convinced that the locking shouldn't be needed at all,
> if you just make sure that you do things in the right order (that, of
> course, might need some memory barriers, which had better be implied by
> the atomic dec-and-test anyway).
You've convinced me that it can be considerably streamlined, which is
great, but it can't all go, and even now there's some missing.
--
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/