Date: Fri, 5 Sep 2014 11:43:05 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica Message-ID: <20140905084305.GN2737@kib.kiev.ua> In-Reply-To: <3070015.668SIdAzOX@ralph.baldwin.cx> References: <201408301748.s7UHmc6H059701@svn.freebsd.org> <201409021100.57493.jhb@freebsd.org> <20140902154127.GD2737@kib.kiev.ua> <3070015.668SIdAzOX@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--x2SxEfr5rzNwq/hH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 04, 2014 at 10:50:25PM -0400, John Baldwin wrote: > On Tuesday, September 02, 2014 06:41:27 PM Konstantin Belousov wrote: > > On Tue, Sep 02, 2014 at 11:00:57AM -0400, John Baldwin wrote: > > > I thought about that. I could easily make a parallel array, or perha= ps > > > use a separate 'susppcb' structure that includes a pcb and the savefpu > > > union and change susppcbs to be an array of those. Which do you pref= er?=20 > > > If we want to move some state out of the PCB on amd64 into this, then= a > > > separate struct for susppcbs might be the sanest. > >=20 > > Yes, separate structure seems to be a way forward. >=20 > Please see www.freebsd.org/~jhb/patches/susppcb.patch Note that I moved > fpususpend() out into a C function on amd64 so that resumectx() could sti= ll=20 > operate on just a pcb. This also makes savectx and resumectx more symmet= ric > and matches what I ended up doing on i386. This is tested for suspend and > resume on both i386 and amd64. The implementation of fpuresume() in C is definitely an improvement. You only moved the fpu context to the susppcb, I think this is good for now, we will want to move other bits later. Do we need to keep pcb layout for KBI compat ? I remember that pcb size is asserted to properly fit into pcpu area for percpu zones. But why keep the layout ? I.e. moving all padding bits to the end. There is one weird detail, not touched by your patch. Amd64 resume path calls initializecpu(), while i386 does not. I do not see any use for the call, the reload of CRX registers by trampoline/resumectx should already set everything to working state. E.g., enabling XMM in CR4 after fpu state is restored looks strange. Overall, it looks fine. Do you prefer to have alloc_fpusave() on i386 ? --x2SxEfr5rzNwq/hH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUCXeYAAoJEJDCuSvBvK1BQOkP/RY8Mb3aL0jGwDDRyTBdPzvV wuPQe+4SFtRdGt7anMzoQTdTMUfuYq8hdlKNbAUOHggZi94cu1IAFstqprHsSbGQ H0YV0+ExpjH8jGMoNDUQwsbOgslYBz4Cu1vvfQSGtkOlUPK1lTrMteyw967AOB9M BZ8nbUEafRHinGyTaod97g6NZo7aVKGZRe93OzvoApgrlAznWnmDs2EkyIIhaY30 FzE5LHML3vgBk93YjKKd00iDJrAtt/AmWRVmix+420yks+Wl5sxhoDLt1Kp7Ll5Q kd1x1EtgGZEdZJqfaXOJt/sHdScG9za8Tq5P4+1HNb61MQjQHQULvxUfuFJ6/sue D1roZQXY7mbGxWo7UKVxX9y6xVp/o97qnjcWcmJ2UYqucn8Ae/OHYrjPrB32pJB2 noPS8WodPqqanvzi4A8OMO/KAIHCMsI0pg6nrsTPuIs+lf9AnRzcjXcV7sf0bc21 mLM+xH6ibT+UdeYL4KQntbAfwT6uov2mTM1WhZg2EddzOrppZ4jWUP4P35WqgMy2 k2tcsPy+3FeA6FMs3dh5cjwa+lVrdogmFA5GWfci/9Kxk+AtN4k0jaRl0i4BQtRV I/cjmi1ZaRfXbIDSOB49fwkdxlEN0xdPNK4SqFanpQNbmn/oQa6r5c8SfLazQfv+ P2iRkSPwNaq2EH0hcVvc =41Qm -----END PGP SIGNATURE----- --x2SxEfr5rzNwq/hH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140905084305.GN2737>