On Thu, Apr 22, 2021 at 13:19, Konstantin Belousov
<[email protected]> wrote:
On Thu, Jan 14, 2021 at 04:23:31AM +0200, Konstantin Belousov wrote:
On Thu, Jan 14, 2021 at 01:36:27AM +0000, myfreeweb wrote:
>
>
> On January 13, 2021 8:58:58 PM UTC, John Baldwin
<[email protected]> wrote:
> >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.
>
> Hmm but with no storage at all, how would it work from a syscall?
> The manpage does mention a "usermode save area" – I was talking
about that.
There is a storage for the user state, always. When NOCTX is used,
FPU state
is spilled into the _current_ save area, and then kernel lives to
the promise
that the new state after fpu_enter(NOCTX) does not ever need to be
saved.
>
> Linux kernel_fpu_begin starts with preempt_disable, so definitely
no condvars and the like. No idea about simple time sleeps. But
amdgpu doesn't seem to do even that.
You should get enough assertions fired if something tries to
context switch
while entered NOCTX region.
So this went dead in the mail, and kernel still contains that awful
code
that corrupts both userspace and kernel FPU contexts.
I suggest to remove this file at all, since things are not being
sorted.
Okay, let's try NOCTX: https://reviews.freebsd.org/D29921
I don't understand how using a full fpu_kern_ctx can *corrupt* anything
though?
It should only be extra overhead?
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "[email protected]"
