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@vger...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/