From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Ongoing/future speculative mitigation work Date: Fri, 26 Oct 2018 09:49:15 +0200 Message-ID: <7b2ff44127f10b0d01e8ed8865c71206c1a8f2f4.camel@suse.com> References: <7079d0ee-a8ef-e164-12d9-8e3bfef81491@citrix.com> <03e84c44-2c33-b00f-bdfc-3c6b57123bfb@citrix.com> <5c251189-cfb7-a36a-5a33-fd661771c9c0@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8593270475349647320==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: Tamas K Lengyel , Andrew Cooper Cc: mpohlack@amazon.de, Julien Grall , Jan Beulich , joao.m.martins@oracle.com, Stefano Stabellini , Daniel Kiper , Marek =?ISO-8859-1?Q?Marczykowski-G=F3recki?= , aliguori@amazon.com, uwed@amazon.de, Lars Kurth , Konrad Rzeszutek Wilk , ross.philipson@oracle.com, George Dunlap , Matt Wilson , Boris Ostrovsky , JGross@suse.com, sergey.dyasli@citrix.com, Wei Liu , George Dunlap , Xen-devel , mdontu , dwmw@amazon.co.uk, Roger Pau =?ISO-8859-1?Q?Monn=E9?= List-Id: xen-devel@lists.xenproject.org --===============8593270475349647320== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-2vsUuv/fuvc+okFBcPLS" --=-2vsUuv/fuvc+okFBcPLS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2018-10-25 at 12:35 -0600, Tamas K Lengyel wrote: > On Thu, Oct 25, 2018 at 12:13 PM Andrew Cooper > wrote: > >=20 > > TBH, I'd perhaps start with an admin control which lets them switch > > between the two modes, and some instructions on how/why they might > > want > > to try switching. > >=20 > > Trying to second-guess the best HT setting automatically is most > > likely > > going to be a lost cause. It will be system specific as to whether > > the > > same workload is better with or without HT. >=20 > This may just not be practically possible at the end as the system > administrator may have no idea what workload will be running on any > given system. It may also vary between one user to the next on the > same system, without the users being allowed to tune such details of > the system. If we can show that with core-scheduling deployed for > most > workloads performance is improved by x % it may be a safe option.=20 > I haven't done this kind of benchmark yet, but I'd say that, if every vCPU of every domain is doing 100% CPU intensive work, core-scheduling isn't going to make much difference, or help you much, as compared to regular scheduling with hyperthreading enabled. Actual numbers may vary depending on whether VMs have odd or even number of vCPUs but, e.g., on hardware with 2 threads per core, and using VMs with at least 2 vCPUs each, the _perfect_ implementation of core-scheduling would still manage to keep all the *threads* busy, which is --as far as our speculations currently go-- what is causing the performance degradation you're seeing. So, again, if it is confirmed that this workload of yours is a particularly bad one for SMT, then you are just better off disabling hyperthreading. And, no, I don't think such a situation is common enough to say "let's disable for everyone by default". > But > if every system needs to be tuned and evaluated in terms of its > eventual workload, that task becomes problematic. > So, the scheduler has the notion of the system load (at least, Credit2 does), and it is in theory possible to put together some heuristics for basically stopping using hyperthreading, upon certain conditions. This, however, I see it as something completely orthogonal from security related consideration and from core-scheduling. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Software Engineer @ SUSE https://www.suse.com/ --=-2vsUuv/fuvc+okFBcPLS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAlvSxvsACgkQFkJ4iaW4 c+5cEA//XWsly8poY9g05bWzqiUt/TQk/4sDd6YsuW/yPq1JSEzOcagci0kdmOoS tJ/eBs6v6Vn1NvZuJX2DafGgEQs3tIHcJUtBQSyUsv9eZ5r9vk+zS0yyiKQzS8cT /A8/a+kaTctZPQdVdn+K57Koq+SUspAmLrMCRtEGzHXfp7sgYLolzOFB0/wvN5AS Xg6n/BtDdnnxv5cNxBmYZyMdy3GtiEqCEejtcIsH+ebt2x+1f+Rlo7vnE3oPZdqt t1HMVSta4LYp9wfgBkIU+Ds2VLrqlPD/rgJAWX1JSH2QbhyNXdDzSmTNCBX7711W WbXrpcwV8KQFOKn6VHS6vZk7DHLX/Nl46afKGsvbwcQzRMnzHskw2D7GZzLoypzw 6w2xsK5COrIA/ae3Gh8i9SzfVIZ1JQjzy/vy2a395DmardACTGsLJhiphGamCj4Y uxdJ5seT3xL9zNZpSoB3REMfbw11sYMMdI3DwmNOVjnCJbk1pm4q9ZqXmSMkLpD9 V7+Y6WXJkOxzvfaIhjDpMKAmI+Jymn3i8EIdeoBZfsNDzcbFokePRrXfsb+uEpS6 wj+2rNHI4JCfMEmL//2GHTHjgkcmFXXXbmBISQVeRd6y5F+UVU0YNqnn/0QcGhlq ukqsWMYm0JJu2s+LfNjLuL+bCkfy48zZgVBQ3D9m77elMxsK8d0= =IZMd -----END PGP SIGNATURE----- --=-2vsUuv/fuvc+okFBcPLS-- --===============8593270475349647320== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============8593270475349647320==--