kernel-packages team mailing list archive

[bugproxy <bugproxy@xxxxxxxxxx>]

------- Comment From preeti.murthy@xxxxxxxxxx 2015-04-09 02:55 EDT-------
(In reply to comment #36)
> > But I'm a bit worried, doesn't not mounting cpuset mean that containers,
> > for instance, wouldn't work so well?
>
> You just won't be able to lock containers to cpusets.
>
> > That is, even if cgmanager doesn't mount the cpuset cgroup, if
> > *anything* mounts it, processes in that cgroup tree will experience the
> > underlying issue, no?
>
> Yes.
>
> And I still think that systemd is currently mounting it regardless
> of cgmanager.
>
> So ideally the effective_cpus thing would be fixed to work for
> non-unified hierarchies.

Ok, so given the situation, I suggest the following:

Fixing this in the kernel will be an ugly hack. Moreover,
userspace must take care of updating cpusets after hotplug
operations. Therefore I see two ways forward:

1. Can systemd/cgmanager (whoever is mounting cgroups) mount
cpuset controllers under the unified hierarchy, while mounting the
rest under the legacy hierarchy? Here is the suggestion from the
community:  https://lkml.org/lkml/2015/4/6/196.

2. Systemd/cgmanager must have a daemon listening to hotplug
events. On hotplug, the parent cgroups cpuset must be percolated
down to the children. This is a better solution because the situation
where cpus are hotplugged in for the first time (i.e from the
cpu_possible_mask to cpu_online_mask), will be handled too.

Can either of the above be done in systemd/cgmanager ?

Regards
Preeti U Murthy

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1392176

Title:
  mounts cgroups unconditionally which causes undesired effects with cpu
  hotplug

Status in cgmanager package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - Preeti U. Murthy <preeti.murthy@xxxxxxxxxx> - 2014-10-20 04:40:12 ==
  ---Problem Description---
  Systemd mounts cgroups explicitly every boot. Since the user had no say in it, undesired consequences are observed in reaction to cpu hotplug operations.  Here is how.

  Systemd moves the tasks to the cgroup mounted by it. This cgroup automatically becomes the child of the root cgroup which is present by default. The children cgroups are not expected to remember their configured cpusets after hotplug operations in the kernel. Hence when cpus are taken offline and brought back online they are no longer used for load balancing of tasks and hence remain unused. 
     This is an undesired consequence because the user had not even asked for cgroups to be mounted, yet is not able to use the full capacity of the system.

  Only when the user himself creates cgroup hierarchies, should he be
  exposed to the side effects of cpu hotplug on cpusets. Else all online
  cpus must be made available to him which is not happening since
  systemd mounts cgroups on every boot.

  Hence please revert this feature or provide an explaination as to why this is being done.
   
  ---uname output---
  Linux tul181p1 3.16.0-18-generic #25-Ubuntu SMP Fri Sep 26 02:39:53 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = Tuleta 8286-42A 
   ---Debugger---
  A debugger was configured, however the system did not enter into the debugger
   
  ---Steps to Reproduce---
   $ taskset -p $$
  $ 0-127
  $ echo 0 > /sys/devices/system/cpu/cpu7/online
  $ taskset -p $$
  $ 0-6,8-127
  $ echo 1 > /sys/devices/system/cpu/cpu7/online
  $ taskset -p $$
  $ 0-6,8-127
   
   
  Userspace tool common name: systemd 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: systemd_208-8ubuntu8_ppc64el.deb

  Userspace tool obtained from project website:   208-8ubuntu8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1392176/+subscriptions