Re: [PATCH] CFS: Fix missing digit off in wmult table

[Ingo Molnar <mingo@elte.hu>]

* Roman Zippel <zippel@linux-m68k.org> wrote:

> > It has been a common request for nice levels to be more logical 
> > (i.e. to make them universal and to detach them from HZ) and for 
> > them to be more effective as well.
> 
> Huh? What has this to do with HZ? The scheduler used ticks internally, 
> but it's irrelevant to what the user sees via the nice levels. [...]

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
-
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/