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.