Re: [SCHED] wrong priority calc - SIMPLE test case



On Sat, 31 Dec 2005 09:13:24 +0100
Mike Galbraith <efault@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages