[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2016-07-18 Thread bugproxy 
--- Comment From ru...@us.ibm.com 2016-07-18 15:08 EDT---
.

-- 
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:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  == Comment: #0 - Preeti U. Murthy  - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2016-06-28 Thread bugproxy 
sudo cat /proc//mountinfo

-- 
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:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  == Comment: #0 - Preeti U. Murthy  - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2016-06-18 Thread bugproxy 
--- Comment From shg...@cn.ibm.com 2016-06-18 09:49 EDT---
(In reply to comment #77)
> "LXC cases, like docker and KVM" - did you mean non-lxc cases?
>
> xenial by default should now be using libpam-cgfs, should not be using
> cgmanager, and should not be creating cpusets.

Thanks for the info. However what I cares is the docker/KVM case. For
example, when I created docker on xenial 16.04, the container process
will still be added into /sys/fs/cgroup/cpuset/docker; When creating
KVM, the KVM process will be added into sub cpuset cgroup as well. As a
result, the issue can still impact those tasks.

For the above, is it already covered(on higher xenial version) or does
it need more consideration?

Regards,
- Simon

-- 
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:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  == Comment: #0 - Preeti U. Murthy  - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2016-06-17 Thread bugproxy 
--- Comment From shg...@cn.ibm.com 2016-06-17 06:01 EDT---
(In reply to comment #63)
>
> @Sqxm - thanks for that input.
>
> For what it's worth you should be able to use ppa:serge-hallyn/systemd in
> xenial to get cpusets not created by default.  Unfortunately I need to make
> some more changes (in particular to use the systemd-created cgroups when
> they exist) before pushing this to the archive.

Serge,
Have these fixes covered LXC cases, like docker and KVM?

If I understand correctly, you mentioned 2 fixes:
- one for cgmanager with libpam-cgm
- another for systemd.

Thanks,
- Simon

-- 
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:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  == Comment: #0 - Preeti U. Murthy  - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-07-12 Thread bugproxy 
--- Comment From bharata@in.ibm.com 2015-07-12 06:07 EDT---
*** Bug 127595 has been marked as a duplicate of this bug. ***

-- 
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
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Preeti U. Murthy preeti.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-06-25 Thread bugproxy 
--- Comment From preeti.mur...@in.ibm.com 2015-06-16 04:50 EDT---
Hi,

An update on this:

We are looking at solving this issue in either of the following two
ways:

1. Have a config option where user specifies the controllers to mount.
2. Have the patch that mounts cgroups for containers in systemd-shim,
rather than systemd.

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
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Preeti U. Murthy preeti.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-04-20 Thread Serge Hallyn 
Quoting bugproxy (bugpr...@us.ibm.com):
 --- Comment From preeti.mur...@in.ibm.com 2015-04-20 03:20 EDT---
 Hi,
 
 We want cgroups to be mounted *without* the cpuset controller.
 
 From your conversation I could make out the following:
 
 1. LXC does not have a hard requirement on cpusets. But the challenge in not 
 mounting
 cpusets would be to teach LXC to identify that all controllers may not be 
 mounted when it
 requests for cgroups.
 
 2. If LXC can identify this, when any container workload asks for cpusets, 
 LXC must fail
 and ask the user to mount cpusets by himself.
 
 3.  But the concern is about workloads that expect cpusets to be mounted 
 implicitly.
 If this is the case, then this is clearly not the way forward.
 
 Is it possible to survey the existing workloads to verify this?

Implement the change and look for breakages :)

I'm still not convinced that we don't want to make the change only for
powerpc systemx - x86 systems AFAIK don't hotplug like drunken sailors.

 Because if there are no
 such workloads, mounting cgroups without cpusets is the simplest way to 
 address
 the problem.
 
 Another approach is the right one, that being having a cgroup hotplug daemon,
 which listens on udev events for cpu hotplug operations and update the allowed
 cpus and mems mask. Such a daemon must be implemented by the service
 which mounts cgroups, which is systemd in this case ? This will take longer 
 to implement ?

It'll require lots of discussion.  If it turns out that upstream is
happy with the feature, it could actually happen very quickly.

-- 
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
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Preeti U. Murthy preeti.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-04-19 Thread bugproxy 
--- Comment From preeti.mur...@in.ibm.com 2015-04-20 03:20 EDT---
Hi,

We want cgroups to be mounted *without* the cpuset controller.

From your conversation I could make out the following:

1. LXC does not have a hard requirement on cpusets. But the challenge in not 
mounting
cpusets would be to teach LXC to identify that all controllers may not be 
mounted when it
requests for cgroups.

2. If LXC can identify this, when any container workload asks for cpusets, LXC 
must fail
and ask the user to mount cpusets by himself.

3.  But the concern is about workloads that expect cpusets to be mounted 
implicitly.
If this is the case, then this is clearly not the way forward.

Is it possible to survey the existing workloads to verify this? Because if 
there are no
such workloads, mounting cgroups without cpusets is the simplest way to address
the problem.

Another approach is the right one, that being having a cgroup hotplug daemon,
which listens on udev events for cpu hotplug operations and update the allowed
cpus and mems mask. Such a daemon must be implemented by the service
which mounts cgroups, which is systemd in this case ? This will take longer to 
implement ?

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
Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  == Comment: #0 - Preeti U. Murthy preeti.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-04-09 Thread bugproxy 
--- Comment From mainam...@in.ibm.com 2015-04-09 09:58 EDT---
*** Bug 121220 has been marked as a duplicate of this bug. ***

-- 
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.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-04-08 Thread bugproxy 
--- Comment From preeti.mur...@in.ibm.com 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.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-04-07 Thread bugproxy 
--- Comment From ara...@us.ibm.com 2015-04-07 15:56 EDT---
(In reply to comment #33)
 Yes Nish, take a look at the full example:

 root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
 user.slice/cpuset.cpus
 0-7
 0-7
 root@ubuntu1504:/sys/fs/cgroup/cpuset# echo 0 
 /sys/devices/system/cpu/cpu7/online
 root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
 user.slice/cpuset.cpus
 0-6
 0-6
 root@ubuntu1504:/sys/fs/cgroup/cpuset# echo 1 
 /sys/devices/system/cpu/cpu7/online
 root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
 user.slice/cpuset.cpus
 0-7
 0-6
 root@ubuntu1504:/sys/fs/cgroup/cpuset# ps aux | grep cgmanager
 root  5761  0.0  0.0   5120  3072 pts/1S+   10:35   0:00 grep
 --color=auto cgmanager
 root 28368  0.0  0.0   4288  3392 ?Ss   10:31   0:00
 /sbin/cgmanager -m name=systemd -M cpuset

I *think* you'd need to have cgmanager's configuration file be correct
at boot-time, and have started your system fresh.

The workaround provided by Serge is to simply not mount the cpuset
cgroup.

So if you have /sys/fs/cgroup/cpuset (or really, `mount | grep cpuset`,
as you can mount it wherever you want) upon boot, then the workaround is
not working. Perhaps something else is mounting cpuset.

But I'm a bit worried, doesn't not mounting cpuset mean that containers,
for instance, wouldn't work so well?

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?

-- 
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.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Kernel-packages] [Bug 1392176] Comment bridged from LTC Bugzilla

2015-04-07 Thread Serge Hallyn 
 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.

-- 
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.mur...@in.ibm.com - 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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp