Re: [PATCH] CFS: Fix missing digit off in wmult table
From: Ingo Molnar
Date: Mon Jul 16 2007 - 09:41:12 EST
* Roman Zippel <zippel@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/