From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from aserp2120.oracle.com ([141.146.126.78]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fIwqw-0005jl-R1 for speck@linutronix.de; Wed, 16 May 2018 15:52:27 +0200 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4GDlsax056056 for ; Wed, 16 May 2018 13:52:20 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2hx29w4xkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 16 May 2018 13:52:20 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4GDqJ2o024461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 16 May 2018 13:52:19 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4GDqJNP020249 for ; Wed, 16 May 2018 13:52:19 GMT Date: Wed, 16 May 2018 09:52:18 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [patch V11 05/16] SSB 5 Message-ID: <20180516135218.GD29202@char.us.oracle.com> References: <20180502215102.192655950@linutronix.de> <20180502215416.459915781@linutronix.de> <20180510175257.GD13616@tassilo.jf.intel.com> <20180510183058.GJ27358@char.us.oracle.com> <20180510190850.GE13616@tassilo.jf.intel.com> <20180510212232.GT27358@char.us.oracle.com> <20180510222533.GH13616@tassilo.jf.intel.com> <20180510235056.GA27882@char.us.oracle.com> <921a21df-8d50-318a-a4c2-03a5f949474e@redhat.com> MIME-Version: 1.0 In-Reply-To: <921a21df-8d50-318a-a4c2-03a5f949474e@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, May 16, 2018 at 09:55:34AM +0200, speck for Paolo Bonzini wrote: > On 11/05/2018 01:50, speck for Konrad Rzeszutek Wilk wrote: > >> Was this with MSR lists unconditionally, or with MSR list combined with > >> the "wait for the first write" approach? > > It was the unconditional. The patch went through a bunch of iterations and this > > is what we ended up testing - but it showed around 2-3% performance degradation > > when doing TPCC-like workloads. I am trying to track down exactly what hardware > > that was done against. > > FWIW the Xen people found the same. Isn't there some magic in how Oh. I didn't know anybody else cared about TPCC except Oracle. > SPEC_CTRL is implemented, to avoid serialization? As I understand it, it depends on the CPU family - some are latched, while others have it more like a reset button. And some probably do nothing. > > Also we don't use MSR save lists at all, so we might get some fixed > overhead when we change the MSR save count from zero to nonzero. > > Paolo >