Historical speck list archives
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Encrypted Message
Date: Wed, 30 May 2018 09:38:16 -0700	[thread overview]
Message-ID: <fd47db24-daed-3e5b-56f5-8fd3ed7cb984@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1805292217520.1597@nanos.tec.linutronix.de>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/rfc822-headers; protected-headers="v1", Size: 134 bytes --]

From: Tim Chen <tim.c.chen@linux.intel.com>
To: speck for Thomas Gleixner <speck@linutronix.de>
Subject: Re: L1D-Fault KVM mitigation

[-- Attachment #2: Type: text/plain, Size: 1626 bytes --]

On 05/29/2018 02:14 PM, speck for Thomas Gleixner wrote:
> 
>> yes, with compile workload, the HT speedup was mostly eaten up by
>> overhead.
> 
> So where is the point of the exercise?
> 
> You will not find a generic solution for this problem ever simply because
> the workloads and guest scenarios are too different. There are clearly
> scenarios which can benefit, but at the same time there are scenarios which
> will be way worse off than with SMT disabled.
> 
> I completely understand that Intel wants to avoid the 'disable SMT'
> solution by all means, but this cannot be done with something which is
> obvioulsy creating more problems than it solves in the first place.
> 
> At some point reality has to kick in and you have to admit that there is no
> generic solution and the only solution for a lot of use cases will be to
> disable SMT. The solution for special workloads like the fully partitioned
> ones David mentioned do not need the extra mess all over the place
> especially not when there is ucode assist at least to the point which fits
> into the patch space and some of it really should not take a huge amount of
> effort, like the forced sibling vmexit to avoid the whole IPI machinery.
> 

Having to sync on VM entry and on VM exit and on interrupt to idle sibling
sucks. Hopefully the ucode guys can come up with something
to provide an option that forces the sibling to vmexit on vmexit,
and on interrupt to idle sibling. This should cut the sync overhead in half.
Then only VM entry needs to be synced should we still want to
do co-scheduling.

Thanks.

Tim



  reply	other threads:[~2018-05-30 16:38 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24  9:06 [MODERATED] L1D-Fault KVM mitigation Joerg Roedel
2018-04-24  9:35 ` [MODERATED] " Peter Zijlstra
2018-04-24  9:48   ` David Woodhouse
2018-04-24 11:04     ` Peter Zijlstra
2018-04-24 11:16       ` David Woodhouse
2018-04-24 15:10         ` Jon Masters
2018-05-23  9:45       ` David Woodhouse
2018-05-24  9:45         ` Peter Zijlstra
2018-05-24 14:14           ` Jon Masters
2018-05-24 15:04           ` Thomas Gleixner
2018-05-24 15:33             ` Thomas Gleixner
2018-05-24 15:38               ` [MODERATED] " Jiri Kosina
2018-05-24 17:22                 ` Dave Hansen
2018-05-24 17:30                   ` Linus Torvalds
2018-05-24 23:18               ` [MODERATED] Encrypted Message Tim Chen
2018-05-24 23:28                 ` [MODERATED] Re: L1D-Fault KVM mitigation Linus Torvalds
2018-05-25  8:31                   ` Thomas Gleixner
2018-05-28 14:43                     ` [MODERATED] " Paolo Bonzini
2018-05-25 18:22                 ` [MODERATED] Encrypted Message Tim Chen
2018-05-26 19:14                 ` L1D-Fault KVM mitigation Thomas Gleixner
2018-05-26 20:43                   ` [MODERATED] " Andi Kleen
2018-05-26 20:48                     ` Linus Torvalds
2018-05-27 18:25                       ` Andi Kleen
2018-05-27 18:49                         ` Linus Torvalds
2018-05-27 18:57                           ` Thomas Gleixner
2018-05-27 19:13                           ` [MODERATED] " Andrew Cooper
2018-05-27 19:26                             ` Linus Torvalds
2018-05-27 19:41                               ` Thomas Gleixner
2018-05-27 22:26                                 ` [MODERATED] " Andrew Cooper
2018-05-28  6:47                                   ` Thomas Gleixner
2018-05-28 12:26                                     ` [MODERATED] " Andrew Cooper
2018-05-28 14:40                           ` Paolo Bonzini
2018-05-28 15:56                             ` Thomas Gleixner
2018-05-28 17:15                               ` [MODERATED] " Paolo Bonzini
2018-05-27 15:42                     ` Thomas Gleixner
2018-05-27 16:26                       ` [MODERATED] " Linus Torvalds
2018-05-27 18:31                       ` Andi Kleen
2018-05-29 19:29                   ` [MODERATED] Encrypted Message Tim Chen
2018-05-29 21:14                     ` L1D-Fault KVM mitigation Thomas Gleixner
2018-05-30 16:38                       ` Tim Chen [this message]
2018-05-24 15:44             ` [MODERATED] " Andi Kleen
2018-05-24 15:38           ` Linus Torvalds
2018-05-24 15:59             ` David Woodhouse
2018-05-24 16:35               ` Linus Torvalds
2018-05-24 16:51                 ` David Woodhouse
2018-05-24 16:57                   ` Linus Torvalds
2018-05-25 11:29                     ` David Woodhouse
2018-04-24 10:30   ` [MODERATED] Re: ***UNCHECKED*** " Joerg Roedel
2018-04-24 11:09     ` Thomas Gleixner
2018-04-24 16:06       ` [MODERATED] " Andi Kleen
2018-04-24 12:53   ` Paolo Bonzini
2018-05-03 16:20     ` Konrad Rzeszutek Wilk
2018-05-07 17:11       ` Paolo Bonzini
2018-05-16  8:51         ` Jiri Kosina
2018-05-16  8:53           ` Paolo Bonzini
2018-05-21 10:06             ` David Woodhouse
2018-05-21 13:40               ` Thomas Gleixner
  -- strict thread matches above, loose matches on Subject: below --
2018-05-02 21:51 [patch V11 00/16] SSB 0 Thomas Gleixner
2018-05-03  4:27 ` [MODERATED] Encrypted Message Tim Chen
2018-05-17 20:53 SSB status - V18 pushed out Thomas Gleixner
2018-05-18 13:54 ` [MODERATED] Is: Sleep states ?Was:Re: " Konrad Rzeszutek Wilk
2018-05-18 14:29   ` Thomas Gleixner
2018-05-18 19:50     ` [MODERATED] Encrypted Message Tim Chen
2018-05-29 19:42 [MODERATED] [PATCH 0/2] L1TF KVM 0 Paolo Bonzini
     [not found] ` <20180529194240.7F1336110A@crypto-ml.lab.linutronix.de>
2018-05-29 22:49   ` [PATCH 1/2] L1TF KVM 1 Thomas Gleixner
2018-05-29 23:54     ` [MODERATED] " Andrew Cooper
2018-05-30  9:01       ` Paolo Bonzini
2018-06-04  8:24         ` [MODERATED] " Martin Pohlack
2018-06-04 13:11           ` [MODERATED] Is: Tim, Q to you. Was:Re: " Konrad Rzeszutek Wilk
2018-06-04 17:59             ` [MODERATED] Encrypted Message Tim Chen
2018-06-05 23:34             ` Tim Chen
2018-06-05 23:37               ` Tim Chen
2018-06-07 19:11                 ` Tim Chen
2018-06-12 17:29 [MODERATED] FYI - Reading uncached memory Jon Masters
2018-06-14 16:59 ` [MODERATED] Encrypted Message Tim Chen
2019-01-12  1:29 [MODERATED] [PATCH v4 00/28] MDSv4 2 Andi Kleen
2019-01-12  1:29 ` [MODERATED] [PATCH v4 05/28] MDSv4 10 Andi Kleen
2019-01-14 19:20   ` [MODERATED] " Dave Hansen
2019-01-18  7:33     ` [MODERATED] Encrypted Message Jon Masters
2019-01-14 23:39   ` Tim Chen
2019-01-12  1:29 ` [MODERATED] [PATCH v4 10/28] MDSv4 24 Andi Kleen
2019-01-15  1:05   ` [MODERATED] Encrypted Message Tim Chen
2019-02-07 23:41 [MODERATED] [PATCH v3 0/6] PERFv3 Andi Kleen
2019-02-07 23:41 ` [MODERATED] [PATCH v3 2/6] PERFv3 Andi Kleen
2019-02-08  0:51   ` [MODERATED] Re: [SUSPECTED SPAM][PATCH " Andrew Cooper
2019-02-08  9:01     ` Peter Zijlstra
2019-02-08  9:39       ` Peter Zijlstra
2019-02-08 10:53         ` [MODERATED] [RFC][PATCH] performance walnuts Peter Zijlstra
2019-02-15 23:45           ` [MODERATED] Encrypted Message Jon Masters
2019-02-19 12:44 [patch 0/8] MDS basics 0 Thomas Gleixner
2019-02-21 16:14 ` [MODERATED] Encrypted Message Jon Masters
2019-02-20 15:07 [patch V2 00/10] MDS basics+ 0 Thomas Gleixner
2019-02-20 15:07 ` [patch V2 04/10] MDS basics+ 4 Thomas Gleixner
2019-02-20 17:10   ` [MODERATED] " mark gross
2019-02-21 19:26     ` [MODERATED] Encrypted Message Tim Chen
2019-02-21 23:44 [patch V3 0/9] MDS basics 0 Thomas Gleixner
2019-02-21 23:44 ` [patch V3 4/9] MDS basics 4 Thomas Gleixner
2019-02-22  7:45   ` [MODERATED] Encrypted Message Jon Masters
2019-02-22 22:24 [patch V4 00/11] MDS basics Thomas Gleixner
2019-02-22 22:24 ` [patch V4 04/11] x86/speculation/mds: Add mds_clear_cpu_buffer() Thomas Gleixner
2019-02-26 14:19   ` [MODERATED] " Josh Poimboeuf
2019-03-01 20:58     ` [MODERATED] Encrypted Message Jon Masters
2019-03-01 22:14       ` Jon Masters
2019-02-24 15:07 [MODERATED] [PATCH v6 00/43] MDSv6 Andi Kleen
2019-02-24 15:07 ` [MODERATED] [PATCH v6 10/43] MDSv6 Andi Kleen
2019-02-25 16:30   ` [MODERATED] " Greg KH
2019-02-25 16:41     ` [MODERATED] Encrypted Message Jon Masters
2019-02-24 15:07 ` [MODERATED] [PATCH v6 31/43] MDSv6 Andi Kleen
2019-02-25 15:19   ` [MODERATED] " Greg KH
2019-02-25 15:34     ` Andi Kleen
2019-02-25 15:49       ` Greg KH
2019-02-25 15:52         ` [MODERATED] Encrypted Message Jon Masters
2019-02-25 16:00           ` [MODERATED] " Greg KH
2019-02-25 16:19             ` [MODERATED] " Jon Masters
2019-03-01 21:47 [patch V6 00/14] MDS basics 0 Thomas Gleixner
2019-03-01 21:47 ` [patch V6 06/14] MDS basics 6 Thomas Gleixner
2019-03-04  6:28   ` [MODERATED] Encrypted Message Jon Masters
2019-03-01 21:47 ` [patch V6 08/14] MDS basics 8 Thomas Gleixner
2019-03-04  6:57   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  7:06     ` Jon Masters
2019-03-04  8:12       ` Jon Masters
2019-03-05 15:34     ` Thomas Gleixner
2019-03-06 16:21       ` [MODERATED] " Jon Masters
2019-03-01 21:47 ` [patch V6 10/14] MDS basics 10 Thomas Gleixner
2019-03-04  6:45   ` [MODERATED] Encrypted Message Jon Masters
2019-03-01 21:47 ` [patch V6 12/14] MDS basics 12 Thomas Gleixner
2019-03-04  5:47   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  5:30 ` Jon Masters
2019-03-04  1:21 [MODERATED] [PATCH RFC 0/4] Proposed cmdline improvements Josh Poimboeuf
2019-03-04  1:23 ` [MODERATED] [PATCH RFC 1/4] 1 Josh Poimboeuf
2019-03-04  3:55   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  7:30   ` [MODERATED] Re: [PATCH RFC 1/4] 1 Greg KH
2019-03-04  7:45     ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  1:24 ` [MODERATED] [PATCH RFC 3/4] 3 Josh Poimboeuf
2019-03-04  3:58   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04 17:17     ` [MODERATED] " Josh Poimboeuf
2019-03-06 16:22       ` [MODERATED] " Jon Masters
2019-03-04  1:25 ` [MODERATED] [PATCH RFC 4/4] 4 Josh Poimboeuf
2019-03-04  4:07   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 16:43 [MODERATED] Starting to go public? Linus Torvalds
2019-03-05 17:02 ` [MODERATED] " Andrew Cooper
2019-03-05 20:36   ` Jiri Kosina
2019-03-05 22:31     ` Andrew Cooper
2019-03-06 16:18       ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 17:10 ` Jon Masters

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=fd47db24-daed-3e5b-56f5-8fd3ed7cb984@linux.intel.com \
    --to=tim.c.chen@linux.intel.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).