From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Date: Thu, 03 Mar 2005 06:37:41 +0000 Subject: Re: Page fault scalability patch V18: Drop first acquisition of ptl Message-Id: <42274727.2070200@yahoo.com.au> 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> <1109829248.5679.178.camel@gaston> In-Reply-To: <1109829248.5679.178.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 , clameter@sgi.com, Linux Kernel list , linux-ia64@vger.kernel.org, Anton Blanchard Benjamin Herrenschmidt wrote: >>However, if this pte_cmpxchg() thing is used for removing access, then >>sparc64 can't use it. In such a case a race in the TLB handler would >>result in using an invalid PTE. I could "spin" on some lock bit, but >>there is no way I'm adding instructions to the carefully constructed >>TLB miss handler assembler on sparc64 just for that :-) >> > >Can't you add a lock bit in the PTE itself like we do on ppc64 hash >refill ? > > You don't want to do that for all architectures, as I said earlier. eg. i386 can concurrently set the dirty bit with the MMU (which won't honour the lock). So you then need an atomic lock, atomic pte operations, and atomic unlock where previously you had only the atomic pte operation. This is disastrous for performance.