Messages in this thread | | | Date | Sat, 31 Dec 2005 16:11:34 +0100 | From | Paolo Ornati <> | Subject | Re: [SCHED] wrong priority calc - SIMPLE test case |
| |
On Sat, 31 Dec 2005 09:13:24 +0100 Mike Galbraith <efault@gmx.de> wrote:
> Ingo seems to have done something in 2.6.15-rc7-rt1 which defeats your > little proggy. Taking a quick peek at the rt scheduler changes, nothing > poked me in the eye, but by golly, I can't get this kernel to act up, > whereas 2.6.14-virgin does.
Ok, I've sucessfully booted 2.6.15-rc7-rt1 (I think that I was having troubles with Thread Softirqs and/or Thread Hardirqs).
First thing: I've preemption disabled, but it shouldn't matter too much since we are talking about priority calculation...
1) My program isn't defeated at all. If I start it with the same args of the previous examples it "seems" defeated, but it isn't.
Lowering the "cpu burn argument" I can reproduce the problem again:
"./a.out 200 & ./a.out 333"
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5607 paolo 15 0 2396 320 252 R 56.1 0.1 0:06.79 a.out 5606 paolo 15 0 2396 324 252 R 38.7 0.1 0:04.55 a.out 1 root 16 0 2556 552 468 S 0.0 0.1 0:00.28 init
2) Priority fluctuation - very interesting: playing with the only arg my program has I've found this:
./a.out 200 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5628 paolo 15 0 2392 320 252 R 48.5 0.1 0:18.34 a.out
./a.out 300 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5633 paolo 15 0 2392 324 252 S 50.1 0.1 0:09.42 a.out
./a.out 400 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5634 paolo 15 0 2392 320 252 S 66.7 0.1 0:06.31 a.out
./a.out 500 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5638 paolo 25 0 2396 320 252 R 67.7 0.1 0:14.78 a.out
./a.out 700 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5640 paolo 15 0 2392 320 252 S 80.1 0.1 0:25.88 a.out
./a.out 800 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5644 paolo 17 0 2396 320 252 R 79.6 0.1 0:26.54 a.out
In the "./a.out 500" case, the priority starts at something like 16 and then slowly go up to 25 _BUT_ if I start my DD test my cpu-eater priority goes quickly to 16!
The real world test case (transcode) is a bit harder to describe: its priority usually goes up to 25, sometimes I've seen it fluctuating a bit (like go to 19 and then back to 25).
When I start my DD test I've seen basically 2 different behaviours:
A) good PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5788 paolo 25 0 114m 18m 2440 R 82.2 3.7 0:10.16 transcode 5804 paolo 15 0 49860 4500 1896 S 8.5 0.9 0:00.99 tcdecode 5808 paolo 18 0 4952 1520 412 D 5.0 0.3 0:00.36 dd
B) bad PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5743 paolo 18 0 114m 18m 2440 R 75.0 3.7 0:26.79 transcode 5759 paolo 15 0 49864 4500 1896 S 7.8 0.9 0:02.71 tcdecode 5750 paolo 16 0 19840 1136 916 S 1.5 0.2 0:00.23 tcdemux 5201 root 15 0 167m 17m 3336 S 0.8 3.5 0:19.38 X 5764 paolo 18 0 4948 1520 412 R 0.7 0.3 0:00.04 dd
Sometimes happens A and sometimes happens B...
PS: probably all these numbers aren't 100% reproducible... this is what happens on my PC.
-- Paolo Ornati Linux 2.6.15-rc7-rt1 on x86_64 - 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/
| |