Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261980AbVCCQwn (ORCPT ); Thu, 3 Mar 2005 11:52:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262031AbVCCQwn (ORCPT ); Thu, 3 Mar 2005 11:52:43 -0500 Received: from omx1-ext.sgi.com ([192.48.179.11]:57048 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S261980AbVCCQwf (ORCPT ); Thu, 3 Mar 2005 11:52:35 -0500 Date: Thu, 3 Mar 2005 08:52:28 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Benjamin Herrenschmidt cc: "David S. Miller" , Paul Mackerras , Andrew Morton , Linux Kernel list , linux-ia64@vger.kernel.org, Anton Blanchard Subject: Re: Page fault scalability patch V18: Drop first acquisition of ptl In-Reply-To: <1109830313.5680.183.camel@gaston> Message-ID: References: <20050302174507.7991af94.akpm@osdl.org> <20050302185508.4cd2f618.akpm@osdl.org> <20050302201425.2b994195.akpm@osdl.org> <16934.39386.686708.768378@cargo.ozlabs.ibm.com> <20050302213831.7e6449eb.davem@davemloft.net> <1109830313.5680.183.camel@gaston> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1296 Lines: 27 On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote: > > There is no need to provide pte_cmpxchg. If the arch does not support > > cmpxchg on ptes (CONFIG_ATOMIC_TABLE_OPS not defined) > > then it will fall back to using pte_get_and_clear while holding the > > page_table_lock to insure that the entry is not touched while performing > > the comparison. > > Nah, this is wrong :) > > We actually _want_ pte_cmpxchg on ppc64, because we can do the stuff, > but it requires some careful manipulation of some bits in the PTE that > are beyond linux common layer understanding :) Like the BUSY bit which > is a lock bit for arbitrating with the hash fault handler for example. > > Also, if it's ever used to cmpxchg from anything but a !present PTE, it > will need additional massaging (like the COW case where we just > "replace" a PTE with set_pte). We also need to preserve some bits in > there that indicate if the PTE was in the hash table and where in the > hash so we can flush it afterward. You can define your own pte_cmpxchg without a problem ... - 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/