Your message dated Sun, 25 Apr 2021 12:24:47 -0700 (PDT)
with message-id <[email protected]>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #771129,
regarding [lxc] Cpusets don't work
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
771129: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771129
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: lxc
Version: 1:1.0.6-4
Severity: normal
Hello,
Might be I'm misunderstanding something, but I can't get cgroup cpuset
to work with container.
I have it set in config:
lxc.cgroup.cpuset.cpus = 0 (or any other #)
It seems to be applied without error:
lxc-start 1417043385.048 DEBUG lxc_cgfs - cgroup 'cpuset.cpus' set to '0'
# cat /sys/fs/cgroup/cpuset/lxc/C1/cpuset.cpus
0
# lxc-checkconfig
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.17-1-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled
--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled
Yet:
C1# burnP6 & burnP6 & burnP6 & burnP6 & burnP6 & burnP6 & burnP6 &
Results in this on host:
%Cpu0 : 98.7 us, 1.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.3 si,
0.0 st
%Cpu1 : 99.7 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
%Cpu2 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
%Cpu3 : 99.7 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
%Cpu4 : 98.0 us, 1.7 sy, 0.0 ni, 0.3 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
%Cpu5 : 99.7 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
%Cpu6 : 99.7 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
%Cpu7 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si,
0.0 st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
9173 root 20 0 160 4 0 R 98.9 0.0 0:18.44
burnP6
9175 root 20 0 160 4 0 R 98.6 0.0 0:18.43
burnP6
9176 root 20 0 160 4 0 R 98.6 0.0 0:18.24
burnP6
9177 root 20 0 160 4 0 R 98.6 0.0 0:18.43
burnP6
9172 root 20 0 160 4 0 R 98.3 0.0 0:18.33
burnP6
9178 root 20 0 160 4 0 R 97.9 0.0 0:18.39
burnP6
9174 root 20 0 160 4 0 R 97.3 0.0 0:18.21
burnP6
9171 root 20 0 160 4 0 R 93.9 0.0 0:17.71 burnP6
Limiting memory appears to be working as expected. Any ideas?
Regards,
Vedran
--- System information. ---
Architecture: amd64
Kernel: Linux 3.17-1-amd64
Debian Release: jessie/sid
850 unstable ftp.de.debian.org
850 unstable deb-multimedia.org
700 testing ftp.de.debian.org
550 experimental ftp.de.debian.org
500 stable ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
===============================-+-===============
debconf (>= 0.5) | 1.5.54
OR debconf-2.0 |
libapparmor1 (>= 2.6~devel) | 2.9.0-2
libc6 (>= 2.8) |
libcap2 (>= 2.10) |
--- End Message ---
--- Begin Message ---
Hi
This bug was filed for a very old kernel or the bug is old itself
without resolution.
If you can reproduce it with
- the current version in unstable/testing
- the latest kernel from backports
please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.
Regards,
Salvatore
--- End Message ---
