Re: RFC: IRQ affinity (aka interrupt routing)

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

Thank you for reviewing.

(2014/08/26 5:15), Mindaugas Rasiukevicius wrote:
> Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost> wrote:
> > Sorry, I typo the patch URL.
> >
> > (2014/08/20 18:06), Kengo NAKAHARA wrote:
> > > and here is the patch
> > >       http://knakahara.github.io/patches/netbsd/irq-affinity-initctl.patch
> >
> >          http://knakahara.github.io/patches/netbsd/irq-affinity-intrctl.patch
>
> Have to admit that I did not read the patch carefully, but why
> io_interrupt_sources_lock is __cpu_simple_lock?  Why not to re-use
> cpu_lock?  The locking itself does not seem to be correct either.

Because I wanted to avoid lock contention between IRQ affinity
and process affinity (in paticular sys__sched_setaffinity() in
sys/kern/sys_sched.c), but now I find it is a wrong idea.
I should delete __cpu_simple_lock and modify to re-use cpu_lock.

> How much of the IRQ affinity code (in x86/intr.c) is actually MD?
> It seems that a lot of that can be made MI (think of kern/subr_intr.c).

I think MI part of IRQ affinity code is not so much, however MI code
surely exists. So, I divide MD part from MI code as much as possible,
and then I move MI code to kern/subr_intr.c.

> Also, please do not forget to add the BSD license text for the newly
> created files.

Yes, I add the BSD license text.

Thanks,

--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>