Messages in this thread | | | Date | Wed, 18 Nov 2015 13:16:09 +0100 | Subject | Re: irq_fpu_usable() is irreliable | From | "Jason A. Donenfeld" <> |
| |
Hi Ingo,
Thanks for looking into this.
On Wed, Nov 18, 2015 at 7:55 AM, Ingo Molnar <mingo@kernel.org> 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 performance variety; I want the FPU but sometimes don't have it, that coy mistress. This happens in the ndo_start_xmit() path of a network driver, which executes with a non-zero softirq_count(). This means that in_interrupt() will be true and interrupted_user_mode() will be false (confirmed by my tests and by Thomas' assertions). What isn't clear is why interrupted_kernel_fpu_idle() is false. In a strange twist of fate, interrupted_kernel_fpu_idle() is true and thus irq_fpu_usable() is true when sending TCP packets, but interrupted_kernel_fpu_idle() is false and thus irq_fpu_usable() is false when sending UDP packets. I haven't found anything along the UDP path that might result in the FPU being used, leaving me a bit flummoxed.
So, my inquiries have lead in two directions: 1. Why would interrupted_kernel_fpu_idle() be false here? And does interrupted_kernel_fpu_idle() depend on what userspace is doing? Or is it entirely limited to behavior inside the kernel? 2. Most of the time ndo_start_xmit() is reached via a syscall (sys_write or similar). I know there's a softirq_count() for all sorts of reasons involving the networking stack, but pretty please - can't there be some way for irq_fpu_usable() to always be true when the entry point is a syscall?
> 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.
> Third, could you post such a problematic stack trace?
Sure: https://paste.kde.org/pfhhdchs9/7mmtvb
Regards, Jason
| |