lkml.org 
[lkml]   [2012]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd
On Thu, 5 Apr 2012, Tejun Heo wrote:

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

But it's not fine to put kthreadd in a cgroup to monitor cpu or memory of
workqueues? We're using the forking property of attaching all children to
the same cgroup as its parent. Modules calling daemonize() get reparented
to kthreadd but are not moved amongst cgroups in which they were created,
why wouldn't they be attached to the root cgroup too if you're going to
mandate this for all cgroups? We need no cpuset or cpu consideration here
because daemonize() does not adjust the cpu affinity of the user thread.

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

How does kthreadd's placement conflict with the long-term direction of
cgroups? We don't need to have a hierarchy for monitoring, we can easily
iterate over all memcgs or cpu cgroups that house kernel threads or other
daemons and add their memory.usage_in_bytes or cpuacct.usage if we want
the aggregate. The point is that we want to monitor the memory and cpu of
a set of tasks and cgroups is naturally the perfect interface for doing
this and already has cgroups such as memcg and cpuacct that allow it.


\
 
 \ /
  Last update: 2012-04-06 00:57    [W:0.087 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site