From owner-freebsd-amd64@FreeBSD.ORG Mon Jul 9 19:26:51 2012 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAFCA106564A; Mon, 9 Jul 2012 19:26:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2B78FC0A; Mon, 9 Jul 2012 19:26:48 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q69JQq9p073401; Mon, 9 Jul 2012 22:26:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q69JQdd7077639; Mon, 9 Jul 2012 22:26:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q69JQdfZ077638; Mon, 9 Jul 2012 22:26:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Jul 2012 22:26:39 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120709192639.GT2338@deviant.kiev.zoral.com.ua> References: <20120708150225.GA2338@deviant.kiev.zoral.com.ua> <201207091124.52044.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UefMXxAhg/xpzpuf" Content-Disposition: inline In-Reply-To: <201207091124.52044.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: amd64@freebsd.org, freebsd-current@freebsd.org Subject: Re: XSAVEOPT X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 19:26:51 -0000 --UefMXxAhg/xpzpuf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 09, 2012 at 11:24:52AM -0400, John Baldwin wrote: > On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote: > > Please find at > > http://people.freebsd.org/~kib/misc/xsaveopt.1.patch > > a patch to finally add suport for using XSAVEOPT for our amd64 context > > switch code. See Intel SDM for description of the XSAVEOPT instruction. > >=20 > > Summary is that the instruction allows to not write parts of the FPU > > state which was not touched by the thread. Context switch then would > > write less to the PCB when thread is moved out from CPU. This is mainly > > to facilitate the ever-growing size of the FPU register file, in > > particular, AVX/YMM registers. Normal applications do not touch YMM, so > > saving them on each context switch if FPU was used is waste. > >=20 > > Main complication is that any consumer of the ucontext_t still expect to > > see fully populated machine state, including the extended states which = were > > not saved. Since CPU only avoids save when corresponding state is prist= ine, > > we can use the copy of initial state. CPUID provides an enumerator that > > allows OS to easily pick up neccesary area and copy over. > >=20 > > I tried hard, but was unable to measure any statistically significant > > difference in the context switch times between XSAVE and XSAVEOPT using > > lmbench lat_ctx, on Core i7 2600K. >=20 > Hmm, I thought one of the ideas of xsaveopt was to let you just always ex= ecute > it during a context switch and dispense with the need for using the CR0_T= S=20 > flag at all? Maybe that isn't true though. It would seem rather silly to > switch out the state if you don't need to (when preempting a thread that = uses=20 > the FPU to run a thread that doesn't and then switching back for example). To always execute XSAVEOPT, we would need always execute XRSTOR. Not executing XSAVEOPT is always faster then executing it. In fact, during the testing, I never seen a situation when x87 of XMM areas would be not saved by XSAVEOPT. Only YMM registers were omited if the process did not touched them since start. --UefMXxAhg/xpzpuf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/7MG8ACgkQC3+MBN1Mb4j4hgCgtmMK7yKhh+XkYS/zNyMM3rCf qUEAoO4WsJjXHDVs3A3wcbC/1oVDRjGG =drT7 -----END PGP SIGNATURE----- --UefMXxAhg/xpzpuf--