Re: [PATCH RFC] smt nice introduces significant lock contention

[Con Kolivas <kernel@kolivas.org>]

On Saturday 03 June 2006 08:58, Chen, Kenneth W wrote:
> You haven't answered my question either.  What is the benefit of special
> casing the initial stage of cpu resource competition?  Is it quantitatively
> measurable?  If so, how much and with what workload?

Ah you mean what the whole point of smt nice is? Yes it's simple enough to do. 
Take the single hyperthreaded cpu with two cpu bound workloads. Let's say I 
run a cpu bound task nice 0 by itself and it completes in time X. If I boot 
it with hyperthread disabled and run a nice 0 and nice 19 task, the nice 0 
task gets 95% of the cpu and completes in time X*0.95. If I boot with 
hyperthread enabled and run the nice 0 and nice 19 tasks, the nice 0 task 
gets 100% of one sibling and the nice 19 task 100% of the other sibling. The 
nice 0 task completes in X*0.6. With the smt nice code added it completed in 
X*0.95. The ratios here are dependent on the workload but that was the 
average I could determine from comparing mprime workloads at differing nice 
and kernel compiles. There is no explicit way on the Intel smt cpus to tell 
it which sibling is running lower priority tasks (sprinkling mwaits around at 
regular intervals is not a realistic option for example).

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/