Re: [ANNOUNCE][RFC] PlugSched-6.2 for 2.6.16-rc1 and 2.6.16-rc1-mm1
From: Peter Williams
Date: Mon Jan 23 2006 - 18:58:56 EST
Paolo Ornati wrote:
On Mon, 23 Jan 2006 11:49:33 +1100
Peter Williams <pwil3058@xxxxxxxxxxxxxx> wrote:
However, in spite of the above, the fairness mechanism should have been
able to generate enough bonus points to get dd's priority back to less
than 34. I'm still investigating why this didn't happen.
Problem solved. It was a scaling issue during the calculation of
expected delay. The attached patch should fix both the CPU hog problem
and the fairness problem. Could you give it a try?
Mmmm... it doesn't work:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5516 paolo 34 0 115m 18m 2432 S 87.5 3.7 0:23.72 transcode
5530 paolo 34 0 51000 4472 1872 S 8.0 0.9 0:02.29 tcdecode
5523 paolo 34 0 19840 1088 880 R 2.0 0.2 0:00.21 tcdemux
5522 paolo 34 0 22156 1204 972 R 0.7 0.2 0:00.02 tccat
5539 paolo 34 0 4952 1468 372 D 0.7 0.3 0:00.04 dd
5350 root 28 0 167m 16m 3228 S 0.3 3.4 0:03.64 X
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5456 paolo 34 0 115m 18m 2432 D 63.9 3.7 0:48.21 transcode
5470 paolo 37 0 50996 4472 1872 R 6.2 0.9 0:05.20 tcdecode
5493 paolo 34 0 4952 1472 372 R 1.5 0.3 0:00.22 dd
5441 paolo 28 0 86656 21m 15m S 0.2 4.4 0:00.77 konsole
5468 paolo 34 0 19840 1088 880 S 0.2 0.2 0:00.23 tcdemux
Bummer. At least it didn't classify dd as CPU intensive but the
fairness bonus doesn't seem to have kicked in. It's currently awarded
as a "one of" bonus each time a delay is too long and I think that it
needs to be a bit more persistent over time.
Thanks for testing
Peter
--
Peter Williams pwil3058@xxxxxxxxxxxxxx
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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/