Oh, I got it, your example is really problem case, but it's a cpuset
specific.
cfs_period_us and cfs_quota_us are a little different, they limit only
bandwidth
and won't cause anything similar.
For example:
A->B
A cpu.cfs_period_us is set to 100000
If you will try to write 200000 to B cpu.cfs_period_us, you will get a
write error.
(I've tried this on 3.10 Linux kernel). So child period and quota cannot be
greater than a parent ones (of course if parent constraints are set they
are ignored).
The main reason to do this knob is flexibility and behavior similar to
VMWare and
our Parallels Cloud Server 6. Our customers really want it.
By the way, period and quota can be set on running domain.
On 01/13/2016 01:42 PM, Michal Privoznik wrote:
On 13.01.2016 11:17, Alexander Burluka wrote:
You are absolutely right, this patchset allows to set domain top-level
cpu.cfs_period_us and cpu.cfs_quota_us cgroups. Can you please
explain problem case a little bit more detailed? This code does not
affect top-level cpuset cgroup, only quota and period, so there is no
visible troubles for me. Thank you!
Well, I would have to dig into the patches, but in theory, if you have
the following cgroup layout:
A->B->C
where A is the top-level cgroup, B is child of A, C is child of B, then
B is inherently restricted by A, C is inherently restricted by B (and
transitively by A too). Therefore if for instance cpuset in A is set to
0-3, B can be only as good as A or more restrictive. So values for
cpuset in B must be a subset of those in A. And so on. The problem we
were facing just recently and that I'm mentioning was, that in the
picture, libvirt puts vCPUs into C cgroup and don't touch A or B. Now
when user wants to pin vCPUs onto different cpuset, we can simply just
change it in C cgroup. If we, however, were to set cpuset in B too, it
would be impossible for us to change C due to reasoning above.
Now, I am not familiar with CFS and we probably don't allow tuning it at
runtime either. I just want to make sure the reason I am mentioning
above is kept in picture when touching our CGroups code.
If I'm completely off, and just blabbing off the lines, disregard me. I
will probably learn more once I'm through the patches.
Michal
--
Regards,
Alexander Burluka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list