Re: IRQ affinities

From: Max Krasnyanskiy
Date: Wed May 21 2008 - 13:58:24 EST

Hi Paul,

Paul Jackson wrote:
Max wrote:
What I realized now is that all I need is

I suspect that something like you're proposing to do here will answer
your needs, to "tell the kernel to not route IRQs to certain CPUs."

I suspect that other folks will have some additional needs, that perhaps
my idea of May 9, 2008:

How about this. We add two files to each cpuset:
irq_affinity_include # IRQs to direct to CPUs in this cpuset
irq_affinity_exclude # IRQs -not- to direct to these CPUs
where irq_affinity_exclude overrides irq_affinity_include.

could meet.

I saw your earlier email with that proposal. Just had to digest it a bit :) (still catching up with things after vacation).

So, to determine to which CPUs a given interrupt (IRQ) can be directed:
1) Combine (union) the 'cpus' of all the cpusets for which
that IRQ is in that cpusets irq_affinity_include, then
2) Remove (set substraction) the 'cpus' of any cpuset for which
that IRQ is in that cpusets irq_affinity_exclude.

That would work. But wouldn't it be hard for the users to debug things ? I mean if you have a complex cpuset hierarchy it may be hard to figure out why a certain irq is not getting to cpuX and vice versa.
btw How would we represent "all irqs", are you implying that those files contain masks ?
We'll also need to handle conflicts like "irq excluded from all cpusets", etc.
I still prefer "irq as a task" approach. It's very simple and straightforward mapping of an irq -> cpuset, no conflicts, etc. Easy to figure out for the user where an irq will end up.

btw I did not quite get the idea behind the "exclude" part. Why is "include" not enough ? Can you give me an example.

It makes sense to me to deal with your "default_smp_affinity" patch
first, and then come back around and see what remains to be done, and
how to do it, perhaps with additional cpuset based mechanisms such as
the above two irq_affinity_* IRQ masks.

I'm in the process of making a patch for exposing default affinity mask.

Peter, et al: how does Max's planned "default_smp_affinity" patch sound
to you, as the next step we take on this?

I think it makes sense regardless of the cpuset based approach. Seems like a logical extension of the existing interface (ie per IRQ mask plus the default).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at