Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Jul 2012 22:26:39 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        amd64@freebsd.org, freebsd-current@freebsd.org
Subject:   Re: XSAVEOPT
Message-ID:  <20120709192639.GT2338@deviant.kiev.zoral.com.ua>
In-Reply-To: <201207091124.52044.jhb@freebsd.org>
References:  <20120708150225.GA2338@deviant.kiev.zoral.com.ua> <201207091124.52044.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120709192639.GT2338>