[lkml]   [2010]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 09/12] irq: implement IRQ expecting

    On 06/19/2010 11:00 AM, Andi Kleen wrote:
    >> IIUC, it's not to help or optimize polling itself. It just gives us a
    >> way to estimate when the next interrupt would be so that power can be
    >> optimized for non polling cases.
    > Shouldn't the idle governour estimate this already?

    I'm not an expert on the subject. According to Arjan,

    One of the hard cases right now that the C state code has is that it
    needs to predict the future. While it has a ton of heuristics,
    including some is there IO oustanding" ones, libata is a really good
    case: libata will know generally that within one seek time (5 msec
    on rotating rust, much less on floating electrons) there'll be an
    interrupt (give or take, but this is what we can do heuristics for
    on a per irq level). So it's a good suggestion of what the future
    will be like, MUCH better than any hint we have right now... all we
    have right now is some history, and when the next timer is....

    So, it seems like it would help.



     \ /
      Last update: 2010-06-19 11:07    [W:0.020 / U:1.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site