while i agree that the 32msec was too low, i think the problem is that
"make -s -j" is a workload that has no guarantee of "success" on that
system. The box does not have enough RAM to service it and does not have
enough swap to survive it. In make -j, jobs are started without any
throttling whatsoever. _Any_ control mechanism within the kernel can act
as an "accidental throttle": for example IO could artificially slow it
down to reduce job rate and keep RAM usage below the critical level. Or
a kernel bug could cause tasks to be delayed and thus let the make -j
"succeed". Or some bad kernel inefficiency in sys_fork() could have this
effect too. It is very important that we dont look at every random
number that a system can produce as a "benchmark", we really have to
consider what happens behind it.
yep - 32msecs was too low, please try -rc1 too: i've increased the
granularity limit so it should be larger than 32ms. Reduce CONFIG_HZ as
well if you are on a more server-type system.
By increasing the granularity the timings change - one can imagine
workloads where _reducing_ the granularity would result in an effective
throttling of the workload. I'm sure a workload could be constructed on
the old scheduler too where its 100 msecs isnt enough either, only
200msecs would help. That thinking never ends - you cannot tune
non-throttled workloads. We've got to be really careful about this.
Ingo
-
