[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Sep 2018 14:38:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: jsteckli@...zon.de
Cc: David Woodhouse <dwmw@...zon.co.uk>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, juerg.haefliger@....com,
deepa.srinivasan@...cle.com, Jim Mattson <jmattson@...gle.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com>,
linux-mm <linux-mm@...ck.org>, Thomas Gleixner <tglx@...utronix.de>, joao.m.martins@...cle.com,
pradeep.vincent@...cle.com, Andi Kleen <ak@...ux.intel.com>,
Khalid Aziz <khalid.aziz@...cle.com>, kanth.ghatraju@...cle.com,
Liran Alon <liran.alon@...cle.com>, Kees Cook <keescook@...gle.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, chris.hyser@...cle.com,
Tyler Hicks <tyhicks@...onical.com>, John Haxby <john.haxby@...cle.com>,
Jon Masters <jcm@...hat.com>
Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs
in mind (for KVM to isolate its guests per CPU)
On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina <jsteckli@...zon.de> wrote:
>
> I've been spending some cycles on the XPFO patch set this week. For the
> patch set as it was posted for v4.13, the performance overhead of
> compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almost
> completely from TLB flushing. If we can live with stale TLB entries
> allowing temporary access (which I think is reasonable), we can remove
> all TLB flushing (on x86). This reduces the overhead to 2-3% for
> kernel compile.
I have to say, even 2-3% for a kernel compile sounds absolutely horrendous.
Kernel bullds are 90% user space at least for me, so a 2-3% slowdown
from a kernel is not some small unnoticeable thing.
Linus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
