linux-kernel - Re: IRQ affinities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 21 May 2008 10:58:09 -0700
From:	Max Krasnyanskiy <maxk@...lcomm.com>
To:	Paul Jackson <pj@....com>
CC:	a.p.zijlstra@...llo.nl, menage@...gle.com, mingo@...e.hu,
	linux-kernel@...r.kernel.org
Subject: Re: IRQ affinities

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/