Date: Sat, 29 Mar 2014 14:03:40 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Chris Torek <torek@torek.net> Cc: freebsd-hackers@freebsd.org Subject: Re: slight problem with r254457 (kthread_add fix) Message-ID: <20140329120340.GC21331@kib.kiev.ua> In-Reply-To: <201403290136.s2T1aVT6078723@elf.torek.net> References: <20140328142402.GX21331@kib.kiev.ua> <201403290136.s2T1aVT6078723@elf.torek.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--U/fatWn3w9i48dtV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 28, 2014 at 07:36:31PM -0600, Chris Torek wrote: > >The kernel-FPU code only exists for x86. >=20 > I'm a bit surprised kernel-mode FPU is not supported on sparc64, > but that does seem to be the case. (Surprising since there *is* > code to use the VIS block-copy instructions, which use the FPU > registers. This seems to be handled as a *very* special case > though: it is called only through cpu_block_copy, and only for > pmap_copy_page, which cannot be re-entered. So it's OK, if > suboptimal. Using the VIS block-copy for other large copies > should be a performance win, but this requires the ability to > re-enter the routine.) >=20 > Anyway, I'm mostly just saying that I can't check the remaining > architectures as I don't know them well enough to tell. If you > do, all is well there. :-) I am sure that only x86 is supported by the KPI, since I only implemented it for x86, and nobody followed up with support for other architectures. x86 also had the 'fast' copy functions which used FPU register file, but they were not fast, and their use also required saving usermode state and disabling interrupts for long time. So I removed that code. >=20 > >Did you tested the patch I posted, for your situation ? >=20 > It took a while to get back to, but yes, it works fine. Thank you, committed as r263912. >=20 > [On cpu_throw:] >=20 > >It seems that you formulation somewhat contradictory. The cpu_throw > >is used only to do the last switch out of the exiting thread. >=20 > Ah, I was thinking of the code paths that get there by calling > sched_throw() with NULL, in the various mp_machdep.c files. > You're looking at the one other code path that reaches > sched_throw() (with a non-NULL argument), in thread_exit(): >=20 > >And indeed, I think that there is a bug, on x86. The CR0.TS must be > >cleared, and fpcurthread must be reset if current cpu still carries > >FPU state of the curthread. At least, I do not see anything which > >would guarantee that CLTS was done before cpu_throw. >=20 > It turns out this is OK because of this: >=20 > cpu_thread_exit(td); /* XXXSMP */ >=20 > cpu_thread_exit() does an fpudrop if needed. >=20 > (I don't think this is a particularly clean design, but it > does work.) You are right. I missed the cpu_thread_exit() doing FPU state drop. --U/fatWn3w9i48dtV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNrabAAoJEJDCuSvBvK1Brm4P/0j8CAKsJGkyC7URvmJoNJcC rCxIUyPubkJxdYqlY57pL7GX/Cu5OPlwF4zjRWkbn74SVFZu5CENkqL76q6JCkj7 PbZXQIbuxB2W+ekBTFrrNukKbjpQHinbGSUAig0AciSNaKTV4kNbth0OB4SAjsqS xVVwDizowi5y9a89E5h/AT+JzL93YFYT9BgWXVhha38SkG4WylJvpHlMRBH+H0UH XGDTPUMaO3oKZwFM1L/XyFvq0pITVIy7S0hCxbOSwZv5QqBXehJfaOQyrM/PDXkg L7uf8mHLRE+SLsftl00koZOW4y/eWEG66cZnjeLT47KI8ozve0DjA4zLJksiLIRl mFNL6LGdwyal0r4DNPv8Y/S3tEhyzK+H2pNHbaNPBBdcMprQYRGtt6VukJiQ0hIZ PBuFTmxuwGOBAG3lPfo8bkwtoCwgAljyR299nOBSEP2KZ/fN8LmLplXfi51cV+Mx qipYD6+H7/NKOy8a0KS4eEAIrQMRtbetWVWDQ3cyFkzbpjSWe67ctz+hHSDuICnv Wzf2x2fRAmaCM897F9omQjioYh3X9ww8i58psTMCcvXzheNcaSeaeQh6hQc3jBH7 3EaJvryXFwl9Gb/buHvzHOq4b1yVUtIpjMJs+Hou+yy5WiyUyL9S+xMtn7DDZsf8 ymyQfmfLEcEmmGmCMoTB =Q6Ng -----END PGP SIGNATURE----- --U/fatWn3w9i48dtV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140329120340.GC21331>