linux-kernel - Re: [RFC/PATCH] cpuset: cpuset 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]

Message-ID: <47C87C28.2010606@qualcomm.com>
Date:	Fri, 29 Feb 2008 13:42:00 -0800
From:	Max Krasnyanskiy <maxk@...lcomm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Paul Jackson <pj@....com>, mingo@...e.hu, tglx@...utronix.de,
	oleg@...sign.ru, rostedt@...dmis.org, linux-kernel@...r.kernel.org,
	rientjes@...gle.com
Subject: Re: [RFC/PATCH] cpuset: cpuset irq affinities

Peter Zijlstra wrote:
> On Fri, 2008-02-29 at 14:55 -0600, Paul Jackson wrote:

>> Do these irqs have any special hardware affinity?  Or are they
>> just consumers of CPU cycles that can be jammed onto whatever CPU(s)
>> we're willing to let be interrupted?
> 
> Depends a bit, the genirq layer seems to allow for irqs that can't be
> freely placed. But most of them can be given a free mask - /me looks @
> tglx/ingo.
We should just check the return value from irq_set_affinity(). If it fails we 
refuse to add it to the set.

>> If for reason of desired hardware affinity, or perhaps for some other
>> reason that I'm not aware of, we wanted to have the combined CPUs in
>> both the 'boot' and 'big_special_app' handle some irq, then we'd be
>> screwed.  We can't easily define, using the cpuset interface and its
>> conventions, a distinct cpuset overlapping boot and big_special_app,
>> to hold that irq.  Any such combining cpuset would have to be the
>> common parent of both the combined cpusets, an annoying intrusion on
>> the expected hierarchy.
>>
>> If the actual set of CPUs we wanted to handle a particular irq wasn't
>> even the union of any pre-existing set of cpusets, then we'd be even
>> more screwed, unable even to force the issue by imposing additional
>> intermediate combined cpusets to meet the need.
> 
> I see the issue. We don't support mv on cgroups, right? To easily create
> common parents...
I guess there maybe some fancy HW topologies that may be a problem but for 
most cases we should be ok.
Simple cases like unmovable IRQs are easy to handle (ie set_affinity() fails 
and we refuse to add it to the cpuset).

>> If there is any potential for this to be a problem, then we should
>> examine the possibility of making irqs their own cgroup, rather than
>> piggy backing them on cpusets (which are now just one instance of a
>> cgroup module.)
> 
> Hmm, but that would then be another controller based on cpus. Might be a
> tad confusing. Might be needed. I'll ponder..
Yeah, I'd prefer it to be along with cpusets. As I mentioned will need similar 
mechanisms for other things besides irqs for complete isolation. Creating a 
separate group for each sounds like an overkill.

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/