unfortunately you are wrong again - there are various HZ related
artifacts in the nice level support code of the old scheduler.
v2.6.22, CONFIG_HZ=100, nice +19 task against a nice-0 CPU-intense task:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2446 mingo 25 0 1576 244 196 R 90.9 0.0 0:32.79 loop
2448 mingo 39 19 1580 248 196 R 9.1 0.0 0:02.94 loop
v2.6.22, CONFIG_HZ=250, nice +19 task against a nice-0 CPU-intense task:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2358 mingo 25 0 1576 248 196 R 96.1 0.0 0:31.97 loop_silent
2363 mingo 39 19 1576 244 196 R 3.9 0.0 0:01.24 loop_silent
v2.6.22, CONFIG_HZ=300, nice +19 task against a nice-0 CPU-intense task:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2332 mingo 25 0 1580 248 196 R 95.1 0.0 0:11.84 loop_silent
2335 mingo 39 19 1576 244 196 R 3.1 0.0 0:00.39 loop_silent
to sum it up: a nice +19 task (the most commonly used nice level in
practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler,
depending on the value of HZ. This is quite inconsistent and illogical.
this HZ dependency of nice levels existed for many years, and the new
scheduler solves that inconsistency - every nice level will get the same
amount of time, regardless of HZ.
Ingo
-