From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 11 Feb 2019 20:17:48 -0000 Received: from userp2120.oracle.com ([156.151.31.85]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gtI1R-000207-Pu for speck@linutronix.de; Mon, 11 Feb 2019 21:17:47 +0100 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1BKDb7f153177 for ; Mon, 11 Feb 2019 20:17:38 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2qhredr2kd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 11 Feb 2019 20:17:38 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1BKHb8i026347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 11 Feb 2019 20:17:37 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x1BKHb5c006408 for ; Mon, 11 Feb 2019 20:17:37 GMT Date: Mon, 11 Feb 2019 15:17:36 -0500 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [RFC][PATCH] performance walnuts Message-ID: <20190211201735.GC11758@char.us.oracle.com> References: <3dd5d6e2bc9ac53f826c251c68ce84fcc79a6872.1549582769.git.ak@linux.intel.com> <20190208090147.GK32477@hirez.programming.kicks-ass.net> <20190208093950.GD32534@hirez.programming.kicks-ass.net> <20190208105318.GE32534@hirez.programming.kicks-ass.net> <20190208180753.GC16922@tassilo.jf.intel.com> <20190211104044.GW32511@hirez.programming.kicks-ass.net> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Mon, Feb 11, 2019 at 03:06:52PM +0100, speck for Thomas Gleixner wrote: > On Mon, 11 Feb 2019, speck for Peter Zijlstra wrote: > > On Fri, Feb 08, 2019 at 10:07:53AM -0800, speck for Andi Kleen wrote: > > > On Fri, Feb 08, 2019 at 11:53:18AM +0100, speck for Peter Zijlstra wrote: > > > > > > * From here on, the constraint is dynamic. > > > > @@ -3345,6 +3387,26 @@ glp_get_event_constraints(struct cpu_hw_events *cpuc, int idx, > > > > return c; > > > > } > > > > > > > > +static bool allow_tsx_force_abort = true; > > > > > > The default needs more discussion. > > > > This is what Thomas wants and makes sense to me. I'm done talking about > > this. > > Again. The broken functionality is TSX. As the cure for TSX requires to > steal a performance counter, the ucode default of preferring TSX causes a > regression on the perf side for no good reason. This is already bad enough > for updates where the ucode comes independent of the kernel update. > > But with the kernel we surely have no reason to follow the Intel marketing > decision and make the same unreasonable default. There is one known > workload which depends on TSX and it's very reasonable to make this one add > the command line option and not punish everyone else. > > > > > + /* > > > > + * Without TFA we must not use PMC3. > > > > + */ > > > > + if (!allow_tsx_force_abort && test_bit(3, c->idxmsk)) { > > > > > > This still needs the extra changes in my patchkit to allow user/kvm opt-in/out. > > > > It needs no such thing. Userspace has the one knob. > > > > And I want to hear from Thomas and Paolo on what KVM wants; Andrew > > already said he doesn't want this crap exposed to virt. And the less I > > have to worry about virt the happier I am. > > For virt the issue is even worse because letting the guest enable TSX > causes the host to have a counter stolen. So it's a host decision in the > first place. If the host decides that TSX has to abort, then the guest has > no choice whatsoever. If the host already decided to lose the counter then > it can allow the guest to fiddle with the abort state. Whether we want to > go there is a different question. Paolo? One extra wrinkle - if TSX aborting is enabled should KVM not expose any perf counters at all to the guest? That would make this a whole lot more simpler. And also not expose the TSX functionality (aka mask the CPUID) to the guest?