From: Jon Masters <jcm@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 1/1] SMTDOC 0
Date: Sun, 8 Jul 2018 20:25:41 -0400 [thread overview]
Message-ID: <52693f45-5e7f-3ef0-8354-874ab0b61cd3@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1807081220260.1589@nanos.tec.linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On 07/08/2018 06:22 AM, speck for Thomas Gleixner wrote:
> On Sat, 7 Jul 2018, speck for Andi Kleen wrote:
>>> And yes, we should clearly describe facts and not the wishful thinking of
>>> Intel. I'm so tired of this marketing drivel.
>>
>> The benchmarks I saw didn't show significant overhead for "real" workloads.
>>
>> Of course you can always construct some worst case, but basing
>> your decisions purely on worst cases is usually not a good strategy.
>
> It's still wrong not to clearly tell that this can have significant impact
> under certain conditions. VMEXIT heavy scenarios exist in reality.
Just to add, according to the numbers I've seen, it takes upwards of 512
cycles (double on older parts) to refill the L1D on Skylake. That's not
huge, but it's not free. And it's not a complete mitigation on its own.
It seems to make most sense to go with what Jiri and Linus have said.
In case it's helpful to have a comparison example though, and because
not everyone here may be aware of it, POWER9 is vulnerable to original
Meltdown and the currently upstream mitigation is to do an L1D$ flush on
every return to userspace or hypervisor exit. Essentially, the same as
is being described here, with also a similarly fast L2->L1 refill. They
added a fast L1D$ flush instruction via millicode similar to Intel's.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
next prev parent reply other threads:[~2018-07-09 0:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-05 22:31 [MODERATED] [PATCH 1/1] SMTDOC 0 Andi Kleen
2018-07-06 20:52 ` [MODERATED] " Josh Poimboeuf
2018-07-06 22:11 ` Andi Kleen
2018-07-06 23:00 ` Jiri Kosina
2018-07-06 23:04 ` Jiri Kosina
2018-07-06 23:46 ` Linus Torvalds
2018-07-07 3:05 ` Andi Kleen
2018-07-07 3:37 ` Linus Torvalds
2018-07-07 8:53 ` Thomas Gleixner
2018-07-07 17:15 ` [MODERATED] " Linus Torvalds
2018-07-07 20:02 ` Thomas Gleixner
2018-07-08 3:35 ` [MODERATED] " Andi Kleen
2018-07-08 10:22 ` Thomas Gleixner
2018-07-09 0:25 ` Jon Masters [this message]
2018-07-07 8:58 ` Thomas Gleixner
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=52693f45-5e7f-3ef0-8354-874ab0b61cd3@redhat.com \
--to=jcm@redhat.com \
--cc=speck@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).