Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

[Tejun Heo]

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
--
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/