Re: [SCHED] wrong priority calc - SIMPLE test case
From: Mike Galbraith
Date: Tue Jan 10 2006 - 10:16:59 EST
At 02:53 PM 1/10/2006 +0100, Paolo Ornati wrote:
On Tue, 10 Jan 2006 14:01:36 +0100
Mike Galbraith <efault@xxxxxx> wrote:
> > > Can you please try this version? It tries harder to correct any
> >
> >It seems that you have forgotten the to attach the patch...
>
> Drat. At least I'm not the first to ever do so :)
This version basically works like the the previous, except that it makes
the priority adjustment faster (that is fine).
However I can fool it the same way.
"./a.out 7000"
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5459 paolo 22 0 2392 288 228 S 71.3 0.1 0:09.47 a.out
"./a.out 3000"
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5493 paolo 19 0 2396 292 228 R 49.8 0.1 0:14.42 a.out
"./a.out 1500"
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5495 paolo 18 0 2396 288 228 S 33.4 0.1 0:09.60 a.out
Fooling it:
"./a.out 7000 & ./a.out 6537 & ./a.out 6347 & ./a.out 5873 &"
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5502 paolo 19 0 2392 288 228 R 27.0 0.1 0:05.64 a.out
5503 paolo 19 0 2396 288 228 R 26.0 0.1 0:07.50 a.out
5505 paolo 19 0 2396 292 228 R 25.6 0.1 0:07.24 a.out
5504 paolo 18 0 2392 288 228 R 21.0 0.1 0:06.78 a.out
(priorities fluctuate between 18/19)
Again with more of them:
./a.out 7000 & ./a.out 6537 & ./a.out 6347 & ./a.out 5873& ./a.out 6245 &
./a.out 5467 &
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5525 paolo 18 0 2396 288 228 R 26.4 0.1 0:07.48 a.out
5521 paolo 19 0 2396 288 228 R 22.0 0.1 0:09.00 a.out
5524 paolo 19 0 2392 288 228 R 19.6 0.1 0:07.21 a.out
5523 paolo 19 0 2392 288 228 R 13.0 0.1 0:10.60 a.out
5520 paolo 19 0 2392 288 228 R 11.0 0.1 0:08.46 a.out
5522 paolo 19 0 2396 288 228 R 7.8 0.1 0:07.14 a.out
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5528 paolo 18 0 2392 288 228 R 19.7 0.1 0:18.15 a.out
5533 paolo 15 0 2396 288 228 S 19.3 0.1 0:19.12 a.out
5531 paolo 18 0 2396 288 228 R 18.5 0.1 0:19.23 a.out
5532 paolo 17 0 2392 288 228 R 15.1 0.1 0:18.55 a.out
5529 paolo 18 0 2396 288 228 R 14.7 0.1 0:13.05 a.out
5530 paolo 18 0 2392 288 228 R 12.5 0.1 0:20.42 a.out
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5530 paolo 18 0 2392 288 228 R 21.0 0.1 0:25.42 a.out
5533 paolo 18 0 2396 288 228 R 20.2 0.1 0:24.75 a.out
5529 paolo 18 0 2396 288 228 R 16.2 0.1 0:17.68 a.out
5532 paolo 18 0 2392 288 228 R 14.8 0.1 0:23.33 a.out
5531 paolo 18 0 2396 288 228 R 14.4 0.1 0:23.96 a.out
5528 paolo 18 0 2392 288 228 R 13.6 0.1 0:23.03 a.out
I don't think it's being fooled, it's pulling these guys down, it's just
that the plausible limit goes up the more tasks you're sharing the cpu
with, so they hit the throttle less. If you start a bunch of tasks who
only do a short burn such that their individual cpu usage isn't much, but
together they use all available cpu, you can still severely starve
non-sleeping == low priority tasks. This patch won't help for that...
that's an entirely different problem, and fortunately one that doesn't seem
to happen much in real life otherwise folks would be bitching like
crazy. To guard against it, there are a lot of different things you can
do. All of the ways that I know of are very bad for the desktop user, and
fortunately for me, beyond the intended scope of this patch :)
-Mike
-
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/