[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190218204020.GV32494@hirez.programming.kicks-ass.net>
Date: Mon, 18 Feb 2019 21:40:20 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Paul Turner <pjt@...gle.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
subhra.mazumdar@...cle.com,
Frédéric Weisbecker <fweisbec@...il.com>,
Kees Cook <keescook@...omium.org>, kerrnel@...gle.com
Subject: Re: [RFC][PATCH 00/16] sched: Core scheduling
On Mon, Feb 18, 2019 at 09:49:10AM -0800, Linus Torvalds wrote:
> On Mon, Feb 18, 2019 at 9:40 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > However; whichever way around you turn this cookie; it is expensive and nasty.
>
> Do you (or anybody else) have numbers for real loads?
>
> Because performance is all that matters. If performance is bad, then
> it's pointless, since just turning off SMT is the answer.
Not for these patches; they stopped crashing only yesterday and I
cleaned them up and send them out.
The previous version; which was more horrible; but L1TF complete, was
between OK-ish and horrible depending on the number of VMEXITs a
workload had.
If there were close to no VMEXITs, it beat smt=off, if there were lots
of VMEXITs it was far far worse. Supposedly hosting people try their
very bestest to have no VMEXITs so it mostly works for them (with the
obvious exception of single VCPU guests).
It's just that people have been bugging me for this crap; and I figure
I'd post it now that it's not exploding anymore and let others have at.
Powered by blists - more mailing lists