From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 01 Oct 2019 00:26:33 -0000 Received: from mga17.intel.com ([192.55.52.151]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iF5zs-0008EC-14 for speck@linutronix.de; Tue, 01 Oct 2019 02:26:32 +0200 Date: Mon, 30 Sep 2019 17:20:56 -0700 From: Pawan Gupta Subject: [MODERATED] Re: [PATCH v4 03/10] TAAv4 3 Message-ID: <20191001002055.GB8582@guptapadev.amr> References: <20190904055711.GC7212@kroah.com> <20190904061155.GI7212@kroah.com> <20190904075846.GD1321@guptapadev.amr> <20190904084306.GA4925@kroah.com> <20190904112758.GP3838@dhcp22.suse.cz> <20190925220515.s6ai3sdbyc7jwdi5@treble> MIME-Version: 1.0 In-Reply-To: <20190925220515.s6ai3sdbyc7jwdi5@treble> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Sep 25, 2019 at 05:05:15PM -0500, speck for Josh Poimboeuf wrote: > On Wed, Sep 04, 2019 at 01:27:58PM +0200, speck for Michal Hocko wrote: > > On Wed 04-09-19 10:43:06, speck for Greg KH wrote: > > > On Wed, Sep 04, 2019 at 12:58:47AM -0700, speck for Pawan Gupta wrote: > > > > On Wed, Sep 04, 2019 at 08:11:55AM +0200, speck for Greg KH wrote: > > > > > On Wed, Sep 04, 2019 at 08:01:47AM +0200, speck for Jiri Kosina wrote: > > > > > > On Wed, 4 Sep 2019, speck for Greg KH wrote: > > > > > > > > > > > > > Did we ever have a reason to enable TSX? I thought no one used it as it > > > > > > > just didn't make any sense (as per Linus's old email about this) > > > > > > > > > > > > > > Who will be turning this on? > > > > > > > > > > > > We know about certain database vendor(s) who are somehow making use of TSX > > > > > > for whatever reason, so having such a knob would be nice of us. > > > > > > > > > > So they now need to explicitly enable it? Would that not break their > > > > > existing systems by forcing them to do an additional startup step, or is > > > > > that somehow ok here? > > > > > > > > For cases when the additional startup step is a problem, there is also > > > > a sysfs interface to control TSX after boot. > > > > > > And that extra step could be a problem. You had a machine that had TSX > > > enabled and the program used it. Upgrade your kernel and now you have > > > to add an additional step in order to use this (command line or sysfs). > > > > > > I am asking if this is going to be an issue for those systems that are > > > expecting a working TSX. > > > > Indeed. I was expecting auto|on|off semantic like other knobs with auto > > preserving the current semantic (disable on broken models) and off to > > override. > > In the previous version of this patch set, Thomas requested the default > be 'tsx=off', which is what Pawan has done now in this version. > > But I agree with Greg, that would break existing workloads. So I think > the default needs to be 'tsx=on', along with 'taa=full'. Do we have a consensus on the default, tsx=off, tsx=on or tsx=auto? Thanks, Pawan