Re: caps(2) and FPU

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi Matt, hi all,
:how do you plan to support the FPU in user mode threads?
:Do you agree that we want to keep the lazy context switch?
:
:I had the following idea:
:(1) the kernel continues to use lazy FPU context switches
:(2) the FPU context is saved in user space to an address
:    provided by the process (or the emulation layer)
:(3) there is a flag (in the user space) which is set by
:    the kernel at the activation time of that FPU context
:    and reset afterwards
:(4) a process can use a syscall/sysmessage to set the active
:    FPU context. This means: If it is the real loaded FPU context,
:    because e.g. no other processes/thread wanted the FPU, nothing
:    happens. Otherwise the FPU is marked as invalid and the FPU
:    context is loaded at the next FPU fault.
:(5) a process can "free" a FPU context. That means the kernel forces
:    a FPU save, if that context is loaded, otherwise it is a no-op.
 
    Keep in mind that userland can save and restore the FP context
    just fine on its own, the kernel need not get involved in
    thread switches being done in userland.

    Initially we should just do an unconditional FPU save/restore
    in userland, but there is no reason why it could not be augmented
    and made more fancy. 

    I agree that many 'threads' will not need the FPU and such an
    optimization would be beneficial.  It should be possible to do
    a lazy FPU save and/or restore in userland though it might
    require a little kernel support to generate an upcall instead of
    a signal for the exception.

:The kernel has to keep the loaded and the wanted FPU context
:in the virtual CPU structure, but no actual FPU context.i
:
:This increases the user space thread switch by one syscall
:and a FPU fault at the first FPU operation. It is fast in
:situations where the scheduler switches to a new process
:and a FPU switch is running at that moment.
:
:The syscall in (5) can avoided in most situations, when it is not
:needed, by actually checking that there is an active context.
:There is no race, since worst that can happen is an unneeded syscall.
:
:Joerg

    I don't intend for userland thread switches to have to enter the
    kernel at all.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>