Messages in this thread | | | Date | Thu, 5 Apr 2012 15:24:00 -0700 | From | Tejun Heo <> | Subject | Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd |
| |
Hello, David.
On Thu, Apr 05, 2012 at 03:03:06PM -0700, David Rientjes wrote: > Yes, they act system-wide but that doesn't mean their memory usage or cpu > need to be accounted together. The key is that all cgroups, current or > future, aren't necessarily for limiting those system-wide resources but > rather can provide useful insight into their cost by monitoring either > their memory or cpu through these two cgroups. > > kthreadd certainly is not the only system-wide resource on the kernel; so > why are you not arguing that all PF_KTHREAD threads not be allowed into > non-root cgroups? We actually have many kthreads in a memcg that _is_ > limited to a specific amount of memory together with other system daemons > that are killable if it becomes oom. > > The reason we're discussing kthreadd here is because it has the funny > ability to fork other kthreads that become PF_THREAD_BOUND. Usually the > only PF_THREAD_BOUND threads are ones created at boot. However, if a > kthread is started for a specific cpu, it gets this bit set to stay on > that cpu via kthread_bind(). That's what causes an inconsistency for only > two types of cgroups: cpusets and cpu and we don't allow them to move > amongst them because of that.
That and because ramifications of putting kthreadd is difficult to predict it being the root of all kthreads. It's fine to be able to put specific kthreads into cgroups if doing such makes sense for that type of kthreads.
> That's what this patch series addresses. Please don't unnecessarily limit > our ability with kthreadd or kthreads in general for accounting of system > activity.
I can see your point but the problem is that it conflicts with the long term direction cgroup is taking and that cgroup seems generally over-engineered to allow too many things which aren't too necessary to the point where it's a giant pain in the ass for the subsystems and people involved, so I'm far more likely to go for chopping down and restricting stuff if it's not strictly necessary. Somethings are just stupid to allow and constrict future development and maintenance unnecessarily which tends to be more important than supporting some acrobatic use cases.
It's not like we have concrete plan regarding single hierarchy thing at the moment, so it could be possible to support the use case you're describing but please bear in mind that such use case might not be of high priority. Hmm... I'll think more about it.
Thanks.
-- tejun
| |