Re: RFC: IRQ affinity (aka interrupt routing)

[David Young <dyoung%pobox.com@localhost>]

On Fri, Jul 25, 2014 at 07:15:02PM +0900, Kengo NAKAHARA wrote:
> Hi martin,
> 
> Thank you very much for your comment.
> 
> (2014/07/25 18:15), Martin Husemann wrote:
> >A few general comments:
> >
> >  - best UI is no UI - the kernel should distribute interrupts automatically
> >    (if possible) as fair as possible over time doiing some statistics
> 
> I agree the computer should distribute interrupts automatically, but
> I think balancing interrupts is too complex for the kernel. So I think
> the balancing should be done by the userland daemon which use the UI.
> Implementing and tuning the userland daemon are future works.

What's the goal of balancing interrupts?  Controlling latency?  That's
important, but it seems like other considerations might apply.  For
example, funneling all interrupts to one core might allow the other
cores to idle in a power-saving state.  Also, it might help to avoid
cacheline motion for two interrupts involved in the same network flow to
fire on the same CPU.

Can you explain why you think that balancing interrupts is too complex
for the kernel?  I would not necessarily disagree, but it seems like
the kernel has the most immediate access to the relevant interrupt
statistics *and* the responsibility for CPU scheduling, so it's in a
pretty good position to react to imbalances.

Dave

> >  - a UI to wire some device interrupts to a special CPU would be ok,
> >    I prefer a new intrctrl for that
> >
> >  - vmstat -i could gain an additional column with the current target cpu
> >    of the interrupt
> 
> I am afraid of breaking backward compatibility, so I avoid to change
> existing commands.
> 
> >  - the device name is nice, but what about shared interrupts?
> 
> I forgot shared interrupts... In the current implement, the device name
> is overwritten by the device established later. Of course this is ugly,
> so I must fix it.
> 
> 
> Thanks,
> 
> -- 
> //////////////////////////////////////////////////////////////////////
> Internet Initiative Japan Inc.
> 
> Device Engineering Section,
> Core Product Development Department,
> Product Division,
> Technology Unit
> 
> Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981