From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266048AbUHPOjR (ORCPT ); Mon, 16 Aug 2004 10:39:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267651AbUHPOjR (ORCPT ); Mon, 16 Aug 2004 10:39:17 -0400 Received: from holomorphy.com ([207.189.100.168]:34471 "EHLO holomorphy.com") by vger.kernel.org with ESMTP id S266048AbUHPOjO (ORCPT ); Mon, 16 Aug 2004 10:39:14 -0400 Date: Mon, 16 Aug 2004 07:39:03 -0700 From: William Lee Irwin III To: Christoph Lameter Cc: "David S. Miller" , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: page fault fastpath: Increasing SMP scalability by introducing pte locks? Message-ID: <20040816143903.GY11200@holomorphy.com> Mail-Followup-To: William Lee Irwin III , Christoph Lameter , "David S. Miller" , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org References: <20040815130919.44769735.davem@redhat.com> <20040815165827.0c0c8844.davem@redhat.com> <20040815185644.24ecb247.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 15 Aug 2004, David S. Miller wrote: >> munmap() can destroy pmd and pte tables. somehow we have >> to protect against that, and currently that is having the >> VMA semaphore held for reading, see free_pgtables(). On Sun, Aug 15, 2004 at 08:29:11PM -0700, Christoph Lameter wrote: > It looks to me like the code takes care to provide the correct > sequencing so that the integrity of pgd,pmd and pte links is > guaranteed from the viewpoint of the MMU in the CPUs. munmap is there to > protect one kernel thread messing with the addresses of these entities > that might be stored in another threads register. > Therefore it is safe to walk the chain only holding the semaphore read > lock? Detached pagetables are assumed to be freeable after a TLB flush IPI. Previously holding ->page_table_lock would prevent the shootdowns of links to the pagetable page from executing concurrently with modifications to the pagetable page. Disabling interrupts or otherwise inhibiting the progress of the IPI'ing cpu is needed to prevent dereferencing freed pagetables and incorrect accounting based on contents of about-to-be-freed pagetables. Reference counting pagetable pages may help here, where the final put would be responsible for unaccounting the various things in the pagetable page. -- wli