Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On 2018-10-12 11:07:28 [-0700], Andy Lutomirski wrote: > All these "if" statements in the FPU code are messy and make > understanding and reviewing this code hard. > > Can you prepare a patch for the beginning of your series that removes > fpu->initialized and just ensures that the fpu is always initialized? > This will regress performance, but you should get all that performance > back with TIF_LOAD_FPU. okay, will do. Sebastian
Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On 2018-10-12 11:07:28 [-0700], Andy Lutomirski wrote: > All these "if" statements in the FPU code are messy and make > understanding and reviewing this code hard. > > Can you prepare a patch for the beginning of your series that removes > fpu->initialized and just ensures that the fpu is always initialized? > This will regress performance, but you should get all that performance > back with TIF_LOAD_FPU. okay, will do. Sebastian
Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen wrote: > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > The fpu->initialized flag should not be changed underneath us. This might > > be a > > fallout during the removal of the LazyFPU support. The FPU is marked > > initialized as soon as the state has been set to an initial value. It does > > not > > signal if the CPU's FPU registers are loaded. > > If this is true, then the check for fpu->initialized should also go away. > All these "if" statements in the FPU code are messy and make understanding and reviewing this code hard. Can you prepare a patch for the beginning of your series that removes fpu->initialized and just ensures that the fpu is always initialized? This will regress performance, but you should get all that performance back with TIF_LOAD_FPU.
Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen wrote: > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > The fpu->initialized flag should not be changed underneath us. This might > > be a > > fallout during the removal of the LazyFPU support. The FPU is marked > > initialized as soon as the state has been set to an initial value. It does > > not > > signal if the CPU's FPU registers are loaded. > > If this is true, then the check for fpu->initialized should also go away. > All these "if" statements in the FPU code are messy and make understanding and reviewing this code hard. Can you prepare a patch for the beginning of your series that removes fpu->initialized and just ensures that the fpu is always initialized? This will regress performance, but you should get all that performance back with TIF_LOAD_FPU.
Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > The fpu->initialized flag should not be changed underneath us. This might be a > fallout during the removal of the LazyFPU support. The FPU is marked > initialized as soon as the state has been set to an initial value. It does not > signal if the CPU's FPU registers are loaded. If this is true, then the check for fpu->initialized should also go away. If we were paranoid, we might also add a WARN_ON_ONCE() to make sure our assumption holds true.
Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > The fpu->initialized flag should not be changed underneath us. This might be a > fallout during the removal of the LazyFPU support. The FPU is marked > initialized as soon as the state has been set to an initial value. It does not > signal if the CPU's FPU registers are loaded. If this is true, then the check for fpu->initialized should also go away. If we were paranoid, we might also add a WARN_ON_ONCE() to make sure our assumption holds true.
