[lxc-users] Limiting number of cores in a container

[Fajar A. Nugraha]

Short version: no

Long version:
lxcfs has improved /proc/cpuinfo relevance in the container somewhat,
in the sense that a container should only be able to see the cores
it's allowed to use. However it doesn't have the capability that you
want.

-- 
Fajar

On Sun, Sep 6, 2015 at 9:08 AM, Benoit GEORGELIN - Association Web4all
<benoit.georgelin at web4all.fr> wrote:
>
> This limit the number of cores in a container but if you have one container using 100% of a core,  every containers using the same core will have an 100% core use.
> Even with shares cpu cgroups limits.
>
> Is there any way that one container using core 0 only sees the amount of his own usage in the container whatever the others using the same core do?
> If I.have 5 containers using core 0, they all share this core and if container 1 use 90% you can see the 4 others systems with  cpu usage at 90%
>
> -- envoyé depuis mon téléphone --
>
> De : Stéphane Graber <stgraber at ubuntu.com>
> envoyé : 2015-09-05 8:46 PM
> à: LXC users mailing-list
> Objet: Re: [lxc-users] Limiting number of cores in a container
>
> On Sat, Sep 05, 2015 at 05:09:25PM -0700, Peter Steele wrote:
> > Our application needs to limit the number of cores a container can
> > use. With libvirt-lxc I use the command "virsh setvpus" to set the
> > number of cores a container can use. With this command you only have
> > to specify the number of cores assigned to the container, not a
> > specific core number. I can't seem to find an equivalent for this
> > with LXC. I've found the parameter lxc.cgroup.cpuset.cpus that can
> > be set to bind a container to use a specific CPU (core?), as well as
> > the parameter lxc.cgroup.cpu.shares that can be used to designate a
> > number of CPU "shares" to be assigned to a container, but I'm not
> > exactly sure how this works, especially in the case of
> > over-committing CPU resources.
> >
> > Let's assume we have a system with 16 cores that will be hosting
> > seven containers. Six of these will be limited to two cores each and
> > one will be assigned four cores. With libvirt-lxc I can simply
> > assign the desired CPU count to each container and let the system
> > would decide how the CPUs are scheduled. In fact, if I had a less
> > powerful server, say with 8 cores instead of 16, libvirt would let
> > me over-commit the CPUs assigned to my containers, in exactly the
> > same way one can over-commit CPUs to VMs. This is very useful in our
> > test environment where engineers may not all have high end systems.
> > The CentOS lscpu command accurately reflects the virtual CPU count
> > of the container, despite how many physical CPUs are actually
> > present on the host:
> >
> > # lscpu
> > Architecture: x86_64
> > CPU op-mode(s): 32-bit, 64-bit
> > Byte Order: Little Endian
> > CPU(s): 4
> > On-line CPU(s) list: 0-3
> > Thread(s) per core: 1
> > Core(s) per socket: 1
> > Socket(s): 4
> > NUMA node(s): 1
> >
> > This shows a container with four virtual CPUs.
> >
> > We have an automation system that creates and manages our
> > containers. Due to its pending demise, we're migrating from
> > libvirt-lxc to "stock" LXC and I'm trying to map the various
> > operations used in creating libvirt containers to equivalent
> > operations for LXC containers. It's not entirely clear to me how to
> > deal with this CPU count issue. Can anyone give me some insight on
> > how to setup something at least approximating what we're doing with
> > libvirt-lxc?
> >
> > Thanks.
> >
> > Peter
>
> lxc.cgroup.cpuset.cpus = 0-3
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users