From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Lameter Date: Thu, 03 Mar 2005 16:52:28 +0000 Subject: Re: Page fault scalability patch V18: Drop first acquisition of ptl Message-Id: List-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> In-Reply-To: <1109830313.5680.183.camel@gaston> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Benjamin Herrenschmidt Cc: "David S. Miller" , Paul Mackerras , Andrew Morton , Linux Kernel list , linux-ia64@vger.kernel.org, Anton Blanchard 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 ...