Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754392AbbBTL3z (ORCPT ); Fri, 20 Feb 2015 06:29:55 -0500 Received: from mta-out1.inet.fi ([62.71.2.195]:55087 "EHLO jenni1.inet.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753899AbbBTL3y (ORCPT ); Fri, 20 Feb 2015 06:29:54 -0500 Date: Fri, 20 Feb 2015 13:29:21 +0200 From: "Kirill A. Shutemov" To: Andrew Cooper Cc: Linus Torvalds , "linux-kernel@vger.kernel.org" , "Xen-devel@lists.xen.org" , David Vrabel , Mel Gorman Subject: Re: [Xen-devel] NUMA_BALANCING and Xen PV guest regression in 3.20-rc0 Message-ID: <20150220112921.GA15064@node.dhcp.inet.fi> References: <54E5DFED.9050700@citrix.com> <20150220010506.GA10837@node.dhcp.inet.fi> <54E710D8.9020605@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E710D8.9020605@citrix.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2149 Lines: 49 On Fri, Feb 20, 2015 at 10:47:52AM +0000, Andrew Cooper wrote: > On 20/02/15 01:49, Linus Torvalds wrote: > > On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov > > wrote: > >> I'm feeling I miss very basic background on how Xen works, but why does it > >> set _PAGE_GLOBAL on userspace entries? It sounds strange to me. > > It is definitely strange. I'm guessing that it's some ancient Xen hack > > for the early Intel virtualization that used to have absolutely > > horrendous vmenter/exit costs, including very much the TLB overhead. \ > > > > These days, Intel has address space identifiers, and doesn't flush the > > whole TLB on VM entry/exit, so it's probably pointless to play games > > with the global bit. > > It was introduced in 2006, but has nothing to do with VT-x > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=6f562e72cdc4b7e1519e23be75f812aebbf41db3 > > As long mode drops segment limit checking, the only way to protect a > 64bit PV kernel from its userspace (both of which run in ring3 on user > pages) is to maintain two sets of pagetables and switch between them on > guest kernel/user context switches. The user set lack kernel mappings. > > I can't comment about the performance impact of the patch (way before my > time), but the justification was to try and reduce the overhead of guest > context switches. IIUC, it tries to reduce userspace->kernel switch in guest. It's still hopeless: kernel mappings are always TLB-cold, right? > > I get the feeling that a lot of Xen stuff is that kind of "legacy > > hacks" that should just be cleaned up, but nobody has the energy or > > the interest. > > Time, mainly. > > There certainly are areas which should be up for re-evaluation, given 9 > years of change in hardware. Is Xen PV still widely used? I'm surprised that users can tolerate this kind of overhead. -- Kirill A. Shutemov -- 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/