lkml.org 
[lkml]   [2006]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH RFC] smt nice introduces significant lock contention
Date
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/

\
 
 \ /
  Last update: 2006-06-03 02:05    [W:0.045 / U:1.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site