** Package changed: linux (Ubuntu) => lxc (Ubuntu)
** Changed in: lxc (Ubuntu)
Status: Confirmed => Triaged
** Changed in: lxc (Ubuntu)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification because you are a member of Kernel
Packages, which is
On Thu, Sep 15, 2016 at 06:21:33PM -, Stéphane Graber wrote:
> I'm assuming you have a system that's booted with the right kernel
> option.
>
> Can you check if /sys/devices/system/cpu/possible includes the isolated
> CPU?
>
> If not, then we could copy that value instead of having to parse
I'm assuming you have a system that's booted with the right kernel
option.
Can you check if /sys/devices/system/cpu/possible includes the isolated
CPU?
If not, then we could copy that value instead of having to parse the CPU
ranges from /sys/devices/system/cpu/isolated and substract that from
/sys/devices/system/cpu/isolated tells you which cpus are isolated.
--
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/1623143
Title:
Linux container does not take same cpu configuration as
I thought of looking at Cpus_allowed from the status file of the current
task or of pid 1, but since both of those would be affected by the task
being in a non-root cgroup, we can't rely on that.
--
You received this bug notification because you are a member of Kernel
Packages, which is
So the problem here is that LXD itself DOES NOT touch the cpuset
controller at all.
liblxc does have some initialization code in place which will copy the
parent value for cpuset.cpus and cpuset.mems if cgroup.clone_children
hasn't been set to 1 yet.
So I guess we'd need a change to the cgfsng
@straber: I don't think this is a kernel bug after all.
You said that LXD will not alter the CPU pinning in any way. But it must
write _something_ to cpuset.cpus before you can add any tasks to the
cgroup. So I assume that by "not altering" you mean it just copies the
value from the parent
The good news is that it looks like even though Cpus_allowed says CPU 0
is allowed the scheduler isn't going to actually schedule anything in
the cgroup to that CPU until something induces the cpuset code to
rebuild the scheduler domains. Primarily that would be writing to one of
the cpuset.cpus
It seems that the cpuset cgroup is causing this. Using the script below
I get this output:
In cgroup:
Cpus_allowed: f
Cpus_allowed_list: 0-3
Outside cgroup:
Cpus_allowed: e
Cpus_allowed_list: 1-3
The script:
#!/bin/bash
set -e
export CGDIR=/sys/fs/cgroup/cpuset/cpusets-$$
Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.8
** Tags added: kernel-da-key
** Changed in: linux (Ubuntu)
Importance: Medium => High
--
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/1623143
Title:
Linux container does not take
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
--
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/1623143
Title:
Linux container does not take same cpu configuration as
Seems correct to have this tracked as a kernel bug. Unless you set
limits.cpu in LXD, LXD will not alter the cpu pinning in any way. And
even if it did, it'd do so through the cpuset cgroup, which shouldn't
allow a sub-cgroup to be any more permissive than the root cgroup.
--
You received this
As a workaround, you could do "lxc profile set default limits.cpu 1-2"
which will have LXD setup the cpuset pinning for all containers to avoid
CPU 0.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Summary changed:
- Linux container does not take same cpu affinity as kernet's hosts
+ Linux container does not take same cpu configuration as kernet's hosts
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
15 matches
Mail list logo
