From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 0/2] x86/mm: remove arch-specific PTE/PMD get-and-clear functions Date: Wed, 13 Jun 2012 10:04:04 -0400 Message-ID: <20120613140404.GH5979@phenom.dumpdata.com> References: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1339582845-25659-1-git-send-email-david.vrabel@citrix.com> Sender: linux-kernel-owner@vger.kernel.org To: David Vrabel Cc: xen-devel@lists.xensource.com, "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org List-Id: xen-devel@lists.xenproject.org On Wed, Jun 13, 2012 at 11:20:43AM +0100, David Vrabel wrote: > This series removes the x86-specific implementation of > ptep_get_and_clear() and pmdp_get_and_clear(). > > The principal reason for this is it allows Xen paravitualized guests > to batch the PTE clears which is a significant performance > optimization of munmap() and mremap() -- the number of entries into > the hypervisor is reduced by about a factor of about 30 (60 in 32-bit > guests) for munmap(). > > There may be minimal gains on native and KVM guests due to the removal > of the locked xchg. What about lguest? > > Removal of arch-specific functions where generic ones are suitable > seems to be a generally useful thing to me. > > The full reasoning for why this is safe is included in the commit > message of patch 1 but to summarize. The atomic get-and-clear does > not guarantee that the latest dirty/accessed bits are returned as TLB > as there is a still a window after the get-and-clear and before the > TLB flush that the bits may be updated on other processors. So, user > space applications accessing pages that are being unmapped or remapped > already have unpredictable behaviour. > > David