WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] some performance issue of shadow2 on 2.6 Linux VMX andpo

To: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>, "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] some performance issue of shadow2 on 2.6 Linux VMX andpossible fix
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Thu, 23 Nov 2006 10:22:20 -0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Thu, 23 Nov 2006 02:23:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8C834404208B254EAD4E532C94859869056BEF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccO35XHE1pAhzw/RHKoywrzkxiSxwAB24Xw
Thread-topic: [Xen-devel] some performance issue of shadow2 on 2.6 Linux VMX andpossible fix
> On ia32e system, old Linux 2.6 kernel (previous to 2.6.16) shares one
l4
> page for all processes. At context switch, it replaces old L3 page in
> l4e with the new one. Current shadow discards old shadow page at the
> same time. When context switch (e.g. client/server model) is very
> frequent, it can be a high cost.

[Aside: I think it was 2.6.11 that moved to a proper 4-level pagetable,
but certainly later than RHEL4 and SLES9 kernels shipped]

> One solution is to pin L3 page as well as L4 page. It reserves
previous
> process' L3 shadow page for later use. The test shows it benefits
> benchmark with frequent context switch such as OLTP (server/client),
> CPU2k (multi users) and specjbb (multi warehouses).
> 
> But it also introduces some overhead. As L3 page table is pinned, it
> needs 1+ extra page fault to be unpinned after the process is
> terminated. KB's performance has some impact.

I think for stuff like this we need to use some heuristics to detect old
kernels and enable L3 pining rather than slowing down everyone. E.g.
enabling the heuristic if the number of L4 pages we currently have
shadowed is <= #vcpus. At the very least, we could pin L3 mapped in just
the specific L4 slot used by older linux kernels.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>