Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 18 Feb 2002 21:18:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 18 Feb 2002 21:18:17 -0500 Received: from zeus.kernel.org ([204.152.189.113]:35486 "EHLO zeus.kernel.org") by vger.kernel.org with ESMTP id ; Mon, 18 Feb 2002 21:18:11 -0500 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Linus Torvalds , Rik van Riel Subject: Re: [RFC] Page table sharing Date: Tue, 19 Feb 2002 03:22:21 +0100 X-Mailer: KMail [version 1.3.2] Cc: Hugh Dickins , , Kernel Mailing List , , Robert Love , , Andrew Morton , , In-Reply-To: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On February 19, 2002 03:05 am, Linus Torvalds wrote: > On Mon, 18 Feb 2002, Rik van Riel wrote: > > > > The swapout code can remove a page from the page table > > while another process is in the process of unsharing > > the page table. > > Ok, I'll buy that. However, looking at that, the locking is not the real > issue at all: > > When the swapper does a "ptep_get_and_clear()" on a shared pmd, it will > end up having to not just synchronize with anybody doing unsharing, it > will have to flush all the TLB's on all the mm's that might be implicated. > > Which implies that the swapper needs to look up all mm's some way anyway, Ick. With rmap this is straightforward, but without, what? flush_tlb_all? Maybe page tables should be unshared on swapin/out after all, only on arches that need special tlb treatment, or until we have rmap. > so the locking gets solved that way. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/