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 <[email protected]> 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 <[email protected]> > 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 > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users > > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
