From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="iso-8859-1" From: Daniel Phillips Subject: Re: [RFC] Page table sharing Date: Tue, 19 Feb 2002 03:12:28 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-mm@kvack.org Return-Path: To: Linus Torvalds Cc: Hugh Dickins , dmccr@us.ibm.com, Kernel Mailing List , linux-mm@kvack.org, Robert Love , Rik van Riel , mingo@redhat.com, Andrew Morton , manfred@colorfullife.com, wli@holomorphy.com List-ID: 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/