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:

> Ambitious and I'm not even sure that's even possible without fallback
> default group. There just are things which are system-wide. What's
> wrong with using root cgroup for that?
>

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's what this patch series addresses. Please don't unnecessarily limit
our ability with kthreadd or kthreads in general for accounting of system
activity.


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