git: 11d62b6f31ab - main - linuxkpi: add kernel_fpu_begin/kernel_fpu_end

[John Baldwin]

On 1/13/21 3:42 AM, myfreeweb wrote:
> 
> 
> On January 13, 2021 10:08:26 AM UTC, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>> On Tue, 12 Jan 2021 15:16:55 +0200
>> Konstantin Belousov <kostikbel at gmail.com> wrote:
>>
>>> On Tue, Jan 12, 2021 at 11:43:00AM +0000, Emmanuel Vadot wrote:
>>>> The branch main has been updated by manu:
>>>>
>>>> URL: https://cgit.FreeBSD.org/src/commit/?id=11d62b6f31ab4e99df6d0c6c23406b57eaa37f41
>>>>
>>>> commit 11d62b6f31ab4e99df6d0c6c23406b57eaa37f41
>>>> Author:     Emmanuel Vadot <manu at FreeBSD.org>
>>>> AuthorDate: 2021-01-12 11:02:38 +0000
>>>> Commit:     Emmanuel Vadot <manu at FreeBSD.org>
>>>> CommitDate: 2021-01-12 11:31:00 +0000
>>>>
>>>>     linuxkpi: add kernel_fpu_begin/kernel_fpu_end
>>>>     
>>>>     With newer AMD GPUs (>=Navi,Renoir) there is FPU context usage in the
>>>>     amdgpu driver.
>>>>     The `kernel_fpu_begin/end` implementations in drm did not even allow nested
>>>>     begin-end blocks.
>>>
>>> Does Linux allow more then one thread to execute kernel_fpu_begin ?
>>
>> I actually have no idea, adding Greg to cc.
> 
> Looks like they save the context into the current thread state, so yes? (drm doesn't need that)
> 
> Also they seem to do something FPU_KERN_NOCTX like (??) because they disable preemption inside these blocks.
> (Where does our NOCTX actually store the state?)

It doesn't store at all because threads aren't allowed to sleep in a critical
section, so the thread will never give up the CPU while in the FPU section.  If
threads can voluntarily sleep (cv_wait*, *sleep(), etc.) while using
kernel_fpu_begin(), then NOCTX won't work and we will need something else.

However, the code snippet from the stackoverflow URL I posted earlier looks
exactly like the NOCTX case where we flush the user FPU state to the thread
if the FPU state is "dirty" and then load a clean initial state for use by
the FPU.  It would also seem to never save the kernel FPU state anywhere by
counting on avoiding context switches.  So, I think you probably should just
make this use NOCTX.

-- 
John Baldwin