Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have played around a little bit with CGROUPS and the fair group scheduler ( using kernel version 2.6.31). When you have CGROUPS in a flat structure, with only one layer from the root-cgroup, everything works as you might expect when setting the cpu.shares parameter, i.e. a fraction of the total. But when I experimented with having deeper levels of CGROUPs it did'nt make any sense sometimes.
For example, I had one CGROUP with the maximum number of shares (260000 something) , and two childgroups with quite little shares, 5000. Then I created some cpuhogging processes ( while(1); ) and put most of them in childgroups and one in the parentgroup. The logical thing would be if the parentgroups single process took almost all CPU-time, as it had the maximum number of shares, but instead the processes in the childgroups got the most CPU-time.
I have tried to figure out how it works by looking at the source code, but I can't really understand it. How does the hierarchical structure of the cgroup-tree interact with the flat aspect of it, i.e. siblings? Or do I misunderstand the whole concept?
There is some doco in the source tree, and there has been (quite) some discussion on lkml over the last couple of years.
I have only used it in the context of the original cpusets - in that I would isolate workloads to subset(s) of the available CPUs; but only at (full) CPU boundaries.
Can't be of any more help unfortunately - must look in more detail someday.