All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: jsteckli@amazon.de, David Woodhouse <dwmw@amazon.co.uk>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	juerg.haefliger@hpe.com, deepa.srinivasan@oracle.com,
	Jim Mattson <jmattson@google.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	linux-mm <linux-mm@kvack.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	joao.m.martins@oracle.com, pradeep.vincent@oracle.com,
	Khalid Aziz <khalid.aziz@oracle.com>,
	kanth.ghatraju@oracle.com, Liran Alon <liran.alon@oracle.com>,
	Kees Cook <keescook@google.com>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	chris.hyser@oracle.com, Tyler Hicks <tyhicks@canonical.com>,
	John Haxby <john.haxby@oracle.com>, Jon Masters <jcm@redhat.com>
Subject: Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)
Date: Mon, 3 Sep 2018 08:26:16 -0700	[thread overview]
Message-ID: <20180903152616.GE27886@tassilo.jf.intel.com> (raw)
In-Reply-To: <CA+55aFzHj_GNZWG4K2oDu4DPP9sZdTZ9PY7sBxGB6WoN9g8d=A@mail.gmail.com>

On Sat, Sep 01, 2018 at 02:38:43PM -0700, Linus Torvalds wrote:
> On Fri, Aug 31, 2018 at 12:45 AM Julian Stecklina <jsteckli@amazon.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.

Also the problem is that depending on the workload everything may fit
into the TLBs, so the temporary stale TLB entries may be around
for a long time. Modern CPUs have very large TLBs, and good
LRU policies. For the kernel entries with global bit set and
which are used for something there may be no reason ever to evict.

Julian, I think you would need at least some quantitative perfmon data about
TLB replacement rates in the kernel to show that it's "reasonable"
instead of hand waving.

Most likely I suspect you would need a low frequency regular TLB
flush for the global entries at least, which will increase
the overhead again.

-Andi


  parent reply	other threads:[~2018-09-03 15:27 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-20 21:25 Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU) Konrad Rzeszutek Wilk
2018-08-20 21:48 ` Linus Torvalds
2018-08-20 21:52   ` Woodhouse, David
2018-08-20 22:18     ` Kees Cook
2018-08-20 22:18       ` Kees Cook
2018-08-20 22:27     ` Linus Torvalds
2018-08-20 22:35       ` Tycho Andersen
2018-08-20 22:59         ` Dave Hansen
2018-08-20 23:14           ` David Woodhouse
2018-08-20 23:26             ` Dave Hansen
2018-08-20 23:38               ` Linus Torvalds
2018-08-21  9:57       ` David Woodhouse
2018-08-21 14:01         ` Liran Alon
2018-08-21 14:22           ` David Woodhouse
2018-08-21 23:04             ` Liran Alon
2018-08-30 16:00       ` Julian Stecklina
2018-08-31 15:26         ` Tycho Andersen
2018-09-01 21:38         ` Linus Torvalds
2018-09-01 22:33           ` Wes Turner
2018-09-03 15:36             ` Andi Kleen
2018-09-03 14:51           ` Julian Stecklina
2018-09-12 15:37             ` Julian Stecklina
2018-09-13  6:11               ` Juerg Haefliger
2018-09-17 10:01                 ` Julian Stecklina
2018-09-17 10:01                   ` Julian Stecklina
2018-09-17 10:19                   ` Tycho Andersen
2018-09-17 13:27                   ` Christoph Hellwig
2018-09-14 17:06               ` Khalid Aziz
2018-09-17  9:51                 ` Julian Stecklina
2018-09-18 23:00                   ` Khalid Aziz
2018-09-24 14:45                     ` Stecklina, Julian
2018-09-24 14:45                       ` Stecklina, Julian
2018-10-15  8:07                       ` Khalid Aziz
2018-10-15  8:07                         ` Khalid Aziz
2018-10-24 11:00                         ` Khalid Aziz
2018-10-24 11:00                           ` Khalid Aziz
2018-10-24 15:00                           ` Tycho Andersen
2018-10-24 15:00                             ` Tycho Andersen
2018-09-03 15:26           ` Andi Kleen [this message]
2018-09-04  9:37             ` Julian Stecklina
2018-09-04  9:37               ` Julian Stecklina
2018-09-07 21:30         ` Khalid Aziz
2018-08-31  8:43     ` James Bottomley
2018-08-31  8:43       ` James Bottomley
2018-09-19  1:03     ` Balbir Singh
2018-09-19  1:03       ` Balbir Singh
2018-09-19 15:34       ` Jonathan Adams
2018-09-19 15:38       ` Jonathan Adams
2018-09-19 15:43       ` Jonathan Adams
2018-09-23  2:33         ` Balbir Singh
2018-09-25 14:12           ` Stecklina, Julian
2018-09-25 14:12             ` Stecklina, Julian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180903152616.GE27886@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=chris.hyser@oracle.com \
    --cc=deepa.srinivasan@oracle.com \
    --cc=dwmw@amazon.co.uk \
    --cc=jcm@redhat.com \
    --cc=jmattson@google.com \
    --cc=joao.m.martins@oracle.com \
    --cc=john.haxby@oracle.com \
    --cc=jsteckli@amazon.de \
    --cc=juerg.haefliger@hpe.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=keescook@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=khalid.aziz@oracle.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liran.alon@oracle.com \
    --cc=pradeep.vincent@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tyhicks@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.