From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fIrHm-0006dt-M3 for speck@linutronix.de; Wed, 16 May 2018 09:55:47 +0200 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6B2B4022414 for ; Wed, 16 May 2018 07:55:39 +0000 (UTC) Received: from [10.36.117.154] (ovpn-117-154.ams2.redhat.com [10.36.117.154]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 20BD72157F20 for ; Wed, 16 May 2018 07:55:38 +0000 (UTC) Subject: [MODERATED] Re: [patch V11 05/16] SSB 5 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> From: Paolo Bonzini Message-ID: <921a21df-8d50-318a-a4c2-03a5f949474e@redhat.com> Date: Wed, 16 May 2018 09:55:34 +0200 MIME-Version: 1.0 In-Reply-To: <20180510235056.GA27882@char.us.oracle.com> Content-Type: multipart/mixed; boundary="4Ra7AS3WBGwp7hFBAVKOEIDrB7OCc3siV"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --4Ra7AS3WBGwp7hFBAVKOEIDrB7OCc3siV Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/05/2018 01:50, speck for Konrad Rzeszutek Wilk wrote: >> Was this with MSR lists unconditionally, or with MSR list combined wit= h=20 >> 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 deg= radation > 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 SPEC_CTRL is implemented, to avoid serialization? 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 --4Ra7AS3WBGwp7hFBAVKOEIDrB7OCc3siV--