lkml.org 
[lkml]   [2015]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: irq_fpu_usable() is irreliable
    From
    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


    \
     
     \ /
      Last update: 2015-11-18 14:01    [W:3.323 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site