slight problem with r254457 (kthread_add fix)

[Konstantin Belousov]

On Fri, Mar 28, 2014 at 07:36:31PM -0600, Chris Torek wrote:
> >The kernel-FPU code only exists for x86.
> 
> 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.)
> 
> 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.

> 
> >Did you tested the patch I posted, for your situation ?
> 
> It took a while to get back to, but yes, it works fine.
Thank you, committed as r263912.
> 
> [On cpu_throw:]
> 
> >It seems that you formulation somewhat contradictory.  The cpu_throw
> >is used only to do the last switch out of the exiting thread.
> 
> 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():
> 
> >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.
> 
> It turns out this is OK because of this:
> 
> 	cpu_thread_exit(td);	/* XXXSMP */
> 
> cpu_thread_exit() does an fpudrop if needed.
> 
> (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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140329/f17d6c71/attachment.sig>