Re: IRQ affinities

From: Max Krasnyanskiy
Date: Tue May 20 2008 - 21:22:01 EST

Paul Jackson wrote:
Peter, responding to pj:
What am I missing?
Two points:

- we can't currently set irq affinities for non-existent (aka new) IRQs
- its a shame to duplicate the masks - most of this information would
also be used in the cpuset structure used to place the tasks.

Ok. Let me twist this a turn tighter then.

The first of your two points, a default affinitiy mask for new irqs,
would seem to require a kernel change. But that change could be a
single cpumask, settable in /sys somewhere, specifying the default
affinity. If that's all we needed, it would be easy.
Looks like we arrived at the same conclusion. See my prev reply.
I'm in the process of making a patch for exposing default affinity mask.

The second of your two points, "duplicating masks", seems more delicate.
There is actually no duplication as far as I can see because IRQ layer already has the default_mask variable. It just needs to be exposed via /proc or /sys.

The space of named cpusets (the directory pathnames below the usual
mount point, /dev/cpuset) is not really much more compact than the
set of interesting cpumasks. But I suppose your point is that some
of the -particular- cpumasks already named by the cpuset hierarchy
are tantilizingly close to the set of interesting cpumasks needed for
irq affinity ... close given some combination of union, intersection,
set difference and compliment operations, given my usual bias toward
looking at such things as this using set theory mechanisms. That is,
for example, one might want all the CPUs in cpusets foo, bar and baz,
except the CPUs in cpuset blip, to handle IRQs so and so.

Let me think on that ... it's my nap time now.
This would be an overkill imho.


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