x86, fpu: more eagerfpu cleanups
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 2 repliesIn review
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
| Patch | Rik van Riel |
|---|---|
| Series | R-b R-b R-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/3] x86, fpu: more eagerfpu cleanups
Quoted 7 lines · Oleg Nesterov
Let me send initial kernel_fpu_begin/end cleanups, I believe they make sense anyway and won't conflict with your changes.
This is actually resend, I sent more patches some time ago but they were ignored.
Quoted 7 lines
Note that (I hope) we can do more changes on top of this series, in particular:
- remove all checks from
irq_fpu_usable()exceptin_kernel_fpu- do not abuse FPU in kernel threads, this makes sense even if
use_eager_fpu(), and with or without the changes you proposed.
On top of this series.
Initially I was going to make more changes, but then I decided to delay the cleanups. IMHO this code needs them in any case. math_state_restore() and its usage doesn't look nice. init_fpu() too, and unlazy_fpu(current) is simply wrong afaics. Fortunately the only caller of init_fpu(current) is coredump, so this task can't return to user-mode, still this doesn't look good. And it should be unified with save_init_fpu(). Which has the wrong WARN_ON_ONCE(!__thread_has_fpu(tsk)).
And I am not sure that unlazy_fpu() is correct wrt __kernel_fpu_begin(), but probably this is because I do not know how fpu works. If the nested __save_init_fpu() is fine, then why (before the previous changes) __kernel_fpu_begin() does __thread_clear_has_fpu() first?
Rik, to remind, I think that your changes need 1 + 2 at least, to avoid the performance regression. Perhaps this needs a single patch.
3/3 is not strictly neccessary, but imo it makes sense anyway, even without your changes. And if we add TIF_LOAD_FPU, it would be nice to filter out kthreads automatically.
Could someone review this series?
If this makes any sense, I'll try to make the cleanups later.
Oleg.