lkml.org 
[lkml]   [2016]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] irqchip/jcore: fix lost per-cpu interrupts
    On Sun, Oct 09, 2016 at 01:03:10PM +0200, Thomas Gleixner wrote:
    > On Sun, 9 Oct 2016, Rich Felker wrote:
    > > Ideas for improvement are welcome -- for example the
    > > irq_is_percpu(irq_desc_get_irq(desc)) thing looks rather silly but I
    >
    > See the other mail.
    >
    > > didn't see a better way without poking through abstractions -- but
    > > overall I think this both solves the timer stall issue that I wasted
    > > other people's time on, and addresses the concerns about the J-Core
    > > AIC driver being oblivious to whether an irq is per-cpu.
    >
    > You could put that knowledge into the device tree so you can decide at
    > mapping time whether it is per cpu or not.

    As discussed in the previous thread(s?) on the percpu topic, I'd
    really rather avoid doing this. There's both the conceptual aspect
    that it's redundant information in the DT that's only there for the
    sake of making the kernel irq system happier (i.e. if there were a
    code path to allow it, the handler type could be set at request_irq
    time with knowledge of the flags rather than requiring the irqchip
    driver to already have duplicate knowledge of this), and a couple
    practical issues.

    One simply relates back to redundancy -- I'd like to avoid making the
    DT bigger since it's likely desirable to have the DT embedded in
    internal ROM in ASICs. But the other big issue is that we already have
    devices in the field using the existing DT bindings.

    My preference would just be to keep the branch, but with your improved
    version that doesn't need a function call:

    irqd_is_per_cpu(irq_desc_get_irq_data(desc))

    While there is some overhead testing this condition every time, I can
    probably come up with several better places to look for a ~10 cycle
    improvement in the irq code path without imposing new requirements on
    the DT bindings.

    If that's really not acceptable, an alternative proposal would be a
    new optional DT property that would give the irqchip driver sufficient
    knowledge to bind the proper handler directly at mapping time, and
    then handle_jcore_irq would be needed only in the fallback case where
    this property is missing.

    As noted in my followup to the clocksource stall thread, there's also
    a possibility that it might make sense to consider the current
    behavior of having non-percpu irqs bound to a particular cpu as part
    of what's required by the compatible tag, in which case
    handle_percpu_irq or something similar/equivalent might be suitable
    for both the percpu and non-percpu cases. I don't understand the irq
    subsystem well enough to insist on that but I think it's worth
    consideration since it looks like it would improve performance of
    non-percpu interrupts a bit.

    Rich

    \
     
     \ /
      Last update: 2016-10-09 16:47    [W:5.308 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site