On 06/03/14 10:35, Daniel P. Berrange wrote: > On Thu, Mar 06, 2014 at 12:32:28AM +0100, Martin Pavlásek wrote: >> Hi >> >> I tried to restrict usage of some running VM by cpu.shares (i.e. set to >> 10 from original 1024) on loaded system and it seem doesn't work as I >> expected... all running processes has same CPU usage (by htop) :-/ >> Does anyone has same experience? > The cpu.shares variable doesn't provide absolute restriction on > CPU usage, rather it is doing relative prioritization. > > eg if you have 2 cgroups that are at the same level in the hierarchy > and you give one shares=512 and one shared=1024, then the latter VM > will get twice the CPU scheduler time of the former. If the latter > VM is completely idle though, the former VM will not be capped in any > way. > > If you want absolute caps then you need to use period/quota settings. > Also you want todo this via the virsh schedinfo command, not accessing > cgroups directly. > > Regards, > Daniel Thanks Daniel for reply, nice example! In my case I've got quite weird results guest: dd if=/dev/zero of=/dev/null for simulating heavy load host: dd if=... same as guest (to make host also loaded) host: htop for watching CPU usage (host has only one core), qemu (one VM, two threads) + dd (host) = 99% usage that is correct, as expected host: virsh schedinfo --set cpu_shares=10 <domain-ID> ...but whole load is still distributed equally - still ~30% for each. All processes are under itself default cgroup, so / for host dd and each VM in their own (something like /machine/<domain-name>). I didn't change any cgroup directly in this case. After that qemu processes should shoconsume significantly less cpu than others, isn't it (change "relative priority" from 1024 to 10)? Limiting by period or quota works, but I would be really happy to use just cpu.shares - I don't want to write own process scheduler, weights of cpu sharing is sufficient for me. Do you have idea why this behaviour happen? Regards