Re: IRQ affinities

[Max Krasnyanskiy <maxk@qualcomm.com>]

Hi Paul,

Paul Jackson wrote:
> Max wrote:
>> What I realized now is that all I need is
>> /proc/irq/default_smp_affinity.
> 
> 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).

Max