Re: IRQ affinities

[Max Krasnyanskiy <maxk@qualcomm.com>]

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.

Max