From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com ([134.134.136.126]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fO47B-0007DE-4T for speck@linutronix.de; Wed, 30 May 2018 18:38:22 +0200 References: <20180424090630.wlghmrpasn7v7wbn@suse.de> <20180424093537.GC4064@hirez.programming.kicks-ass.net> <1524563292.8691.38.camel@infradead.org> <20180424110445.GU4043@hirez.programming.kicks-ass.net> <1527068745.8186.89.camel@infradead.org> <20180524094526.GE12198@hirez.programming.kicks-ass.net> <0dacc8a9-3809-2fea-cf77-c15b0a395335@linux.intel.com> From: Tim Chen Message-ID: Date: Wed, 30 May 2018 09:38:16 -0700 MIME-Version: 1.0 In-Reply-To: Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="hnCmeAxxLdmtnL9uTZ9yKCBsBWAs9pbNo"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --hnCmeAxxLdmtnL9uTZ9yKCBsBWAs9pbNo Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Tim Chen To: speck for Thomas Gleixner Subject: Re: L1D-Fault KVM mitigation --hnCmeAxxLdmtnL9uTZ9yKCBsBWAs9pbNo Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/29/2018 02:14 PM, speck for Thomas Gleixner wrote: >=20 >> yes, with compile workload, the HT speedup was mostly eaten up by >> overhead. >=20 > So where is the point of the exercise? >=20 > You will not find a generic solution for this problem ever simply becau= se > the workloads and guest scenarios are too different. There are clearly > scenarios which can benefit, but at the same time there are scenarios w= hich > will be way worse off than with SMT disabled. >=20 > 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. >=20 > At some point reality has to kick in and you have to admit that there i= s no > generic solution and the only solution for a lot of use cases will be t= o > disable SMT. The solution for special workloads like the fully partitio= ned > 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 f= its > into the patch space and some of it really should not take a huge amoun= t of > effort, like the forced sibling vmexit to avoid the whole IPI machinery= =2E >=20 Having to sync on VM entry and on VM exit and on interrupt to idle siblin= g 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 ha= lf. Then only VM entry needs to be synced should we still want to do co-scheduling. Thanks. Tim --hnCmeAxxLdmtnL9uTZ9yKCBsBWAs9pbNo--