On 05/13/2014 05:47 AM, Peter Zijlstra wrote: > On Tue, May 13, 2014 at 11:34:43AM +0800, Michael wang wrote: >> During our testing, we found that the cpu.shares doesn't work as >> expected, the testing is: >> > > /me zaps all the kvm nonsense as that's non reproducable and only serves > to annoy. > > Pro-tip: never use kvm to report cpu-cgroup issues. > >> So is this results expected (I really do not think so...)? >> >> Or that imply the cpu-cgroup got some issue to be fixed? > > So what I did (WSM-EP 2x6x2): > > mount none /cgroup -t cgroup -o cpu > mkdir -p /cgroup/a > mkdir -p /cgroup/b > mkdir -p /cgroup/c > > echo $$ > /cgroup/a/tasks ; for ((i=0; i<12; i++)) ; do A.sh & done > echo $$ > /cgroup/b/tasks ; for ((i=0; i<12; i++)) ; do B.sh & done > echo $$ > /cgroup/c/tasks ; for ((i=0; i<12; i++)) ; do C.sh & done > > echo 2048 > /cgroup/c/cpu.shares > > Where [ABC].sh are spinners:
I suspect the "are spinners" is key. Infinite loops can run all the time, while dbench spends a lot of its time waiting for locks. That waiting may interfere with getting as much CPU as it wants. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/