From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Miller" Date: Thu, 03 Mar 2005 17:43:37 +0000 Subject: Re: Page fault scalability patch V18: Drop first acquisition of ptl Message-Id: <20050303094337.186d63b2.davem@davemloft.net> 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> <42274727.2070200@yahoo.com.au> <1109831428.5680.187.camel@gaston> In-Reply-To: <1109831428.5680.187.camel@gaston> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Benjamin Herrenschmidt Cc: nickpiggin@yahoo.com.au, paulus@samba.org, akpm@osdl.org, clameter@sgi.com, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, anton@samba.org On Thu, 03 Mar 2005 17:30:28 +1100 Benjamin Herrenschmidt wrote: > On Fri, 2005-03-04 at 04:19 +1100, Nick Piggin wrote: > > > 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. > > Of course, but I was answering to David about sparc64 which uses > software TLB load :) Right. The current situation on sparc64 is that the tlb miss handler is ~10 cycles. Like I said, I can use this thing if it just increases access, without modifying the TLB miss handler at all. Hmmm... let me think about this some more.