> On Sep 26, 2018, at 8:32 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-26 07:34:09 [-0700], Andy Lutomirski wrote:
>>> So I *think* nobody relies on FPU-emulation anymore. I would suggest to
>>> get this patch set into shape and then getting rid of
>>> CONFIG_MATH_EMULATION?
>
>
> On Sep 26, 2018, at 8:32 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-26 07:34:09 [-0700], Andy Lutomirski wrote:
>>> So I *think* nobody relies on FPU-emulation anymore. I would suggest to
>>> get this patch set into shape and then getting rid of
>>> CONFIG_MATH_EMULATION?
>
>
On 2018-09-26 07:34:09 [-0700], Andy Lutomirski wrote:
> > So I *think* nobody relies on FPU-emulation anymore. I would suggest to
> > get this patch set into shape and then getting rid of
> > CONFIG_MATH_EMULATION?
Bryan, Denys, does anyone of you rely on CONFIG_MATH_EMULATION?
The manual for
On 2018-09-26 07:34:09 [-0700], Andy Lutomirski wrote:
> > So I *think* nobody relies on FPU-emulation anymore. I would suggest to
> > get this patch set into shape and then getting rid of
> > CONFIG_MATH_EMULATION?
Bryan, Denys, does anyone of you rely on CONFIG_MATH_EMULATION?
The manual for
> On Sep 26, 2018, at 4:12 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-20 21:15:35 [-0700], Andy Lutomirski wrote:
>>> I mean the fpu.initialized variable entirely. AFAIK, its only use is for
>>> kernel threads — setting it to false lets us switch to a kernel thread and
>>> back
> On Sep 26, 2018, at 4:12 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-20 21:15:35 [-0700], Andy Lutomirski wrote:
>>> I mean the fpu.initialized variable entirely. AFAIK, its only use is for
>>> kernel threads — setting it to false lets us switch to a kernel thread and
>>> back
On 2018-09-20 21:15:35 [-0700], Andy Lutomirski wrote:
> > I mean the fpu.initialized variable entirely. AFAIK, its only use is for
> > kernel threads — setting it to false lets us switch to a kernel thread and
> > back without saving and restoring. But TIF_LOAD_FPU should be able to
> >
On 2018-09-20 21:15:35 [-0700], Andy Lutomirski wrote:
> > I mean the fpu.initialized variable entirely. AFAIK, its only use is for
> > kernel threads — setting it to false lets us switch to a kernel thread and
> > back without saving and restoring. But TIF_LOAD_FPU should be able to
> >
> On Sep 20, 2018, at 8:45 PM, Andy Lutomirski wrote:
>
>
>
>> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
>> wrote:
>>
>> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -101,14
> On Sep 20, 2018, at 8:45 PM, Andy Lutomirski wrote:
>
>
>
>> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
>> wrote:
>>
>> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -101,14
> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
>>>
>>> kernel_fpu_disable();
>>>
> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
>>>
>>> kernel_fpu_disable();
>>>
On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
> > --- a/arch/x86/kernel/fpu/core.c
> > +++ b/arch/x86/kernel/fpu/core.c
> > @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
> >
> >kernel_fpu_disable();
> >
> > -if (fpu->initialized) {
> > +__cpu_invalidate_fpregs_state();
On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
> > --- a/arch/x86/kernel/fpu/core.c
> > +++ b/arch/x86/kernel/fpu/core.c
> > @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
> >
> >kernel_fpu_disable();
> >
> > -if (fpu->initialized) {
> > +__cpu_invalidate_fpregs_state();
> On Sep 12, 2018, at 6:33 AM, Sebastian Andrzej Siewior
> wrote:
>
> From: Rik van Riel
>
> Defer loading of FPU state until return to userspace. This gives
> the kernel the potential to skip loading FPU state for tasks that
> stay in kernel mode, or for tasks that end up with repeated
>
> On Sep 12, 2018, at 6:33 AM, Sebastian Andrzej Siewior
> wrote:
>
> From: Rik van Riel
>
> Defer loading of FPU state until return to userspace. This gives
> the kernel the potential to skip loading FPU state for tasks that
> stay in kernel mode, or for tasks that end up with repeated
>
From: Rik van Riel
Defer loading of FPU state until return to userspace. This gives
the kernel the potential to skip loading FPU state for tasks that
stay in kernel mode, or for tasks that end up with repeated
invocations of kernel_fpu_begin.
It also increases the chances that a task's FPU
From: Rik van Riel
Defer loading of FPU state until return to userspace. This gives
the kernel the potential to skip loading FPU state for tasks that
stay in kernel mode, or for tasks that end up with repeated
invocations of kernel_fpu_begin.
It also increases the chances that a task's FPU
18 matches
Mail list logo
