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] [thread-next>] [day] [month] [year] [list]

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

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

--
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/