Re: irq_fpu_usable() is irreliable

* Jason A. Donenfeld wrote: > Intel 3820QM, but inside VMWare Workstation 12. > > > Third, could you post such a problematic stack trace? > > Sure: https://paste.kde.org/pfhhdchs9/7mmtvb So it's: [ 187.194226] CPU: 0 PID: 1165 Comm: iperf3 Tainted: G O 4.2.3-1-ARCH #1

Re: irq_fpu_usable() is irreliable

* Jason A. Donenfeld wrote: > Hi Ingo, > > The plot thickens, once again. > > > > Also, what CPU does the test system have, Intel or AMD? The FPU behavior > > > can be > > > very different in the two cases. > > Intel 3820QM, but inside VMWare Workstation 12. > > Trying this on bare metal,

Re: irq_fpu_usable() is irreliable

* Jason A. Donenfeld wrote: > Hi Ingo, > > The plot thickens, once again. > > > > Also, what CPU does the test system have, Intel or AMD? The FPU behavior > > > can be > > > very different in the two cases. > > Intel 3820QM, but inside VMWare Workstation 12. > > Trying this

Re: irq_fpu_usable() is irreliable

* Jason A. Donenfeld wrote: > Intel 3820QM, but inside VMWare Workstation 12. > > > Third, could you post such a problematic stack trace? > > Sure: https://paste.kde.org/pfhhdchs9/7mmtvb So it's: [ 187.194226] CPU: 0 PID: 1165 Comm: iperf3 Tainted: G O

Re: irq_fpu_usable() is irreliable

Hi Ingo, The plot thickens, once again. > > Also, what CPU does the test system have, Intel or AMD? The FPU behavior > > can be > > very different in the two cases. > Intel 3820QM, but inside VMWare Workstation 12. Trying this on bare metal, the problem goes away! Though the VM is 4.2 and my

Re: irq_fpu_usable() is irreliable

Hi Ingo, Thanks for looking into this. On Wed, Nov 18, 2015 at 7:55 AM, Ingo Molnar wrote: > Is this 'problem' a performance problem (code not being able to use the FPU > occasionally and hence sporadically performing poorly), or some sort of actual > stability/correctness problem? More of the

Re: irq_fpu_usable() is irreliable

Hi Ingo, The plot thickens, once again. > > Also, what CPU does the test system have, Intel or AMD? The FPU behavior > > can be > > very different in the two cases. > Intel 3820QM, but inside VMWare Workstation 12. Trying this on bare metal, the problem goes away! Though the VM is 4.2 and my

Re: irq_fpu_usable() is irreliable

Hi Ingo, Thanks for looking into this. On Wed, Nov 18, 2015 at 7:55 AM, Ingo Molnar wrote: > Is this 'problem' a performance problem (code not being able to use the FPU > occasionally and hence sporadically performing poorly), or some sort of actual > stability/correctness

Re: irq_fpu_usable() is irreliable

* Jason A. Donenfeld wrote: > [...] Recently I've been tracking down a problem in which irq_fpu_usable() > returns false, yet a stack trace shows the first function is the syscall > entry > point. [...] Is this 'problem' a performance problem (code not being able to use the FPU

Re: irq_fpu_usable() is irreliable

Trying to get to the bottom of this still... Is interrupted_kernel_fpu_idle() in any way dependent on what userspace is doing? Or is it entirely related to other happenings inside the kernel? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: irq_fpu_usable() is irreliable

Hi Thomas, On Tue, Nov 17, 2015 at 3:06 PM, Thomas Gleixner wrote: > The real question in your case is WHY interrupted_kernel_fpu_idle() > returns false. We know for sure that in a syscall with BH disabled the > first two checks are false. Blurg, indeed. I've been trying to track that down in a

Re: irq_fpu_usable() is irreliable

Jason, On Tue, 17 Nov 2015, Jason A. Donenfeld wrote: > The availability of the FPU in kernel space, as you know, is determined by > this function: > > bool irq_fpu_usable(void) > { > return !in_interrupt() || > interrupted_user_mode() || >

irq_fpu_usable() is irreliable

Hi folks, The availability of the FPU in kernel space, as you know, is determined by this function: bool irq_fpu_usable(void) { return !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle(); } My understanding is that the first check

irq_fpu_usable() is irreliable

Hi folks, The availability of the FPU in kernel space, as you know, is determined by this function: bool irq_fpu_usable(void) { return !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle(); } My understanding is that the first check

Re: irq_fpu_usable() is irreliable

Jason, On Tue, 17 Nov 2015, Jason A. Donenfeld wrote: > The availability of the FPU in kernel space, as you know, is determined by > this function: > > bool irq_fpu_usable(void) > { > return !in_interrupt() || > interrupted_user_mode() || >

Re: irq_fpu_usable() is irreliable

Hi Thomas, On Tue, Nov 17, 2015 at 3:06 PM, Thomas Gleixner wrote: > The real question in your case is WHY interrupted_kernel_fpu_idle() > returns false. We know for sure that in a syscall with BH disabled the > first two checks are false. Blurg, indeed. I've been trying to

Re: irq_fpu_usable() is irreliable

Trying to get to the bottom of this still... Is interrupted_kernel_fpu_idle() in any way dependent on what userspace is doing? Or is it entirely related to other happenings inside the kernel? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: irq_fpu_usable() is irreliable

* Jason A. Donenfeld wrote: > [...] Recently I've been tracking down a problem in which irq_fpu_usable() > returns false, yet a stack trace shows the first function is the syscall > entry > point. [...] Is this 'problem' a performance problem (code not being able to use the