linux-kernel - Re: IRQ affinities (was: boot cgroup questions)

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20080509073650.045d037d.pj@sgi.com>
Date:	Fri, 9 May 2008 07:36:50 -0500
From:	Paul Jackson <pj@....com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	maxk@...lcomm.com, menage@...gle.com, mingo@...e.hu,
	linux-kernel@...r.kernel.org
Subject: Re: IRQ affinities (was: boot cgroup questions)

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.

The second of your two points, "duplicating masks", seems more delicate.

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.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
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/