Messages in this thread | | | Date | Fri, 29 Feb 2008 13:42:00 -0800 | From | Max Krasnyanskiy <> | 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
| |