** Tags removed: targetmilestone-inin1510
** Tags added: targetmilestone-inin1604
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups unconditionally which causes undesired
I recommend opening new bugs against libvirt and docker. Libvirt moves
VMS into a cpuset by default. I assume docker does the same. (My
xenial laptop runs upstart, so this is not systemd's doing)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
"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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: cgmanager (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: systemd (Ubuntu)
Status: Incomplete => Fix Released
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
** Changed in: cgmanager (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: systemd (Ubuntu)
Status: Incomplete => Fix Released
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
No - this being moot does not apply to wily.
Actually the xenial work has been delayed so it does not *yet* apply
there either.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts
@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
Serge,
Does the issue being moot apply to wiley or 16.04?
Thanks,
Ali
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups unconditionally which causes undesired effects
FYI: My use case for hot plugging my x86 system like a drunken sailor
is to evaluate the amount of CPUs required to complete a given task
before I schedule it to run on other potentially CPU bound machines.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
> 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.
We do on amd64. We run Ubuntu as virtual machine guests and do allow
hot-plugging CPUs. We do not have cgmanager installed.
--
You received this bug
Quoting Benjamin Drung (bdr...@posteo.de):
> > 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.
>
> We do on amd64. We run Ubuntu as virtual machine guests and do allow
> hot-plugging CPUs. We do not
cgmanager (in git, not yet packaged) can now build a pam module which
could be used in place of our systemd patch to move tasks into cgroups
upon login. This would allow simple configuration of the cgroup
controllers to be used. I'm waiting on feedback in private email about
whether or not we
** Tags removed: targetmilestone-inin---
** Tags added: targetmilestone-inin1510
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups unconditionally which causes undesired
Quoting Martin Pitt (martin.p...@ubuntu.com):
Setting systemd task to incomplete for now. Please let me know how we
want the cgroups set up for user sessions, and I'll change our patch
accordingly. Thanks!
I'll discuss this with Stéphane next week.
--
You received this bug notification
Quoting Martin Pitt (martin.p...@ubuntu.com):
Serge Hallyn [2015-04-17 17:49 -]:
Cpusets are not *required* for lxc. Perhaps we should in fact default
to only providing name=systemd, devices and freezer cgroups for users?
We'd want to very widely advertise how to enable other cgroups.
Serge Hallyn [2015-04-17 17:49 -]:
Cpusets are not *required* for lxc. Perhaps we should in fact default
to only providing name=systemd, devices and freezer cgroups for users?
We'd want to very widely advertise how to enable other cgroups.
Right, I mostly understood it so that we need to
Setting systemd task to incomplete for now. Please let me know how we
want the cgroups set up for user sessions, and I'll change our patch
accordingly. Thanks!
** Changed in: systemd (Ubuntu)
Status: New = Incomplete
--
You received this bug notification because you are a member of
Quoting Martin Pitt (martin.p...@ubuntu.com):
Note that when i start up a vivid vm without cgmanager installed, cpuset is
still mounted and login sessions get a cpuset cgroup:
2:cpuset:/user.slice/user-1000.slice/session-1.scope
Note that this is by request of Stèphane, it's an ubuntu
Serge,
This is the output of what you have request.
root@ubuntu1504:/sys/fs/cgroup/cpuset# cat cpuset.cpus ; cat
user.slice/cpuset.cpus
0-7
0-6
root@ubuntu1504:/sys/fs/cgroup/cpuset# cgm listcontrollers
blkio
cpu,cpuacct
devices
freezer
hugetlb
memory
net_cls,net_prio
perf_event
name=systemd
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
(In particular I'm looking to confirm that cgmanager didn't mount
cpuset)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups unconditionally which causes undesired effects
When doing that check, please show the results also of
cgm listcontrollers
sudo cat /proc/$(pidof cgmanager)/mountinfo
cat /proc/self/mountinfo
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Breno,
Was your test done with a cgmanager with the -M flag passed?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups unconditionally which causes undesired effects with
Serge,
That should only be true for unified hierarchy. In legacy hierarchy,
effective_cpus follows cpus, I think?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups
I understand that this problem is still not fixed yet. It should be
reopened:
# taskset -p $$
pid 2523's current affinity mask: ff
# echo 0 /sys/devices/system/cpu/cpu7/online
# taskset -p $$
pid 12787's current affinity mask: 7f
# echo 1 /sys/devices/system/cpu/cpu7/online
# cat
Hope had been that the kernel's new support for cpuset.effective_cpus
would fix this. Removing a cpu from a parent cgroup or offlining a cpu
would remove it from effective_cpus, but not from cpuset.cpus.
Apparently that's not the case (kernel 3.19.0-10-generic was used for
the test in comment
Hope had been that the kernel's new support for cpuset.effective_cpus
would fix this. Removing a cpu from a parent cgroup or offlining a cpu
would remove it from effective_cpus, but not from cpuset.cpus.
Apparently that's not the case (kernel 3.19.0-10-generic was used for
the test in comment
@glaubits,
cgmanager is not for managing but for delegating cgroups, which systemd
does not yet provide. (I'd like to work toward that with the systemd
community) When that is not needed then cgmanager can indeed be removed
- however cpusets still end up being mounted by systemd itself.
Looking into cgmager for Ubuntu vivid,
Correct me if I'm wrong, but the sole reason why cgmanager was conceived
was to have something to manage CGroups when systemd is not running.
And, as Ubuntu 15.04 (vivid), is settling on systemd by default, you can
just uninstall cgmanager as systemd does
It seems this fixed was reverted when cgmanager was upgraded to 0.36.
Looking into cgmager for Ubuntu vivid, I don't see the patch
0001-implement-M-to-support-skip-mounting-certain-control.patch anymore,
also, cgmanager is not being loaded with -M option, as showed:
Quoting Bharata B Rao (1392...@bugs.launchpad.net):
Serge,
What's the recommended way to start cgmanager with -M cpuset ? I added
When running systemd you must edit the file
/lib/systemd/system/cgmanager.service
so that the ExecStart line reads
ExecStart=/sbin/cgmanager -m name=systemd -M
Quoting Breno Leitão (1392...@bugs.launchpad.net):
It seems this fixed was reverted when cgmanager was upgraded to 0.36.
No, I've verified that this still works in 15.04. The patch
implement -M to support skip mounting certain controllers
is a part of the 0.36 release.
--
You received this
Any update on comment #19 ?
Also any plans to get CPU hotplug work seamlessly ? I see that CPU
hotplug is affected by this bug, haven't been able to use -M cpuset
option to verify if that helps CPU hotplug case too.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Serge,
What's the recommended way to start cgmanager with -M cpuset ? I added
cgmanager_opts=-M cpuset in /etc/default/cgmanager but it still starts
w/o -M option.
root@ubuntu1504:~# ps aux | grep cgm
root 624 0.0 0.1 4096 3264 ?Ss 04:58 0:00
/sbin/cgmanager -m
Can you explain what the patch does ? This will help us figure out why
its not working.
The pach is: implement -M to support skip mounting certain controllers
So you need to start cgmanager with -M cpuset to get the behavior you
are looking for.
The changelog entry said:
This doesn't
The patch does not work for us.
We tried out the below test:
root@ubuntu1504:~# cat /etc/issue
Ubuntu Vivid Vervet (development branch) \n \l
root@ubuntu1504:~# cgmanager --version
cgmanager 0.36
root@ubuntu1504:~# uname -a
Linux ubuntu1504 3.18.0-13-generic #14-Ubuntu SMP Fri Feb 6
This bug was fixed in the package cgmanager - 0.35-1ubuntu1
---
cgmanager (0.35-1ubuntu1) vivid; urgency=medium
* 0001-implement-M-to-support-skip-mounting-certain-control.patch:
This doesn't change the default, so may not suffice for powerpc,
but at least offers a
This bug was fixed in the package cgmanager - 0.35-1ubuntu1
---
cgmanager (0.35-1ubuntu1) vivid; urgency=medium
* 0001-implement-M-to-support-skip-mounting-certain-control.patch:
This doesn't change the default, so may not suffice for powerpc,
but at least offers a
Yes, for those tasks which had the offlined cpu in their cpusets before hotplug,
the cpu should be added back to their respective cpusets when it comes online.
Regards
Preeti U Murthy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Branch linked: lp:ubuntu/vivid-proposed/cgmanager
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1392176
Title:
mounts cgroups unconditionally which causes undesired effects with cpu
hotplug
It seems that what you really want is for, when a cpu is on-lined, for
all or some tasks to have that cpu automatically added to their cpuset?
Would that suffice?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The movement of existing tasks to the child cgroups created by
cgmanager/systemd must be avoided as far as I can see.
If the additional cgroups are for LXC containers, the containers and the tasks
spawned within them alone can reside under the children cgroups. Why move the
existing tasks into
Hold on, the actual mounting of the fs is not the problem, right? It's
the movement of tasks into groups on login? So this should perhaps be
fixed in systemd-shim instead?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@preeti,
if it suffices for you to just not run cgmanager at all, then you can
just disable it by doing
echo manual | sudo tee /etc/init/cgmanager.override
Is it specifically only the cpuset cgroup which you do not want mounted
on your systems?
We could add a '-M' option to cgmanager so that
Serge Hallyn [2015-02-03 17:01 -]:
Hold on, the actual mounting of the fs is not the problem, right? It's
the movement of tasks into groups on login? So this should perhaps be
fixed in systemd-shim instead?
Note that upstream systemd does not touch any cgroups other than
systemd. We
Hi,
Is there any update on this front?
We are seeing the effect of this bug in several places on IBM PowerPC platforms
and would like to see it resolved soon. Can the cgroup mounting be made *only*
when the user explicitly asks for it?
Regards
Preeti U Murthy
--
You received this bug
systemd (in the sense of pid 1) doesn't do that. I. e. if you boot with
init=/bin/systemd the only cgroup controller it puts tasks into (by
default) is the systemd one, for that very reason. But if you boot
with upstart (Ubuntu's default still), cgmanager creates cgroups.
cgmanager puts tasks into
systemd (in the sense of pid 1) doesn't do that. I. e. if you boot with
init=/bin/systemd the only cgroup controller it puts tasks into (by
default) is the systemd one, for that very reason. But if you boot
with upstart (Ubuntu's default still), cgmanager creates cgroups.
cgmanager puts tasks into
I'm definately open to making this more flexible.
The queestion is how best to allow the configuration. We could add a
/etc/cgmanager.conf, or we could do it through command line options
specified in /etc/default/cgmanager
** Changed in: cgmanager (Ubuntu)
Status: New = Triaged
**
49 matches
Mail list logo
