Re: [RFC/PATCH] cpuset: cpuset irq affinities

[Max Krasnyanskiy]

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