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

[Paolo Ornati <ornati@fastwebnet.it>]

On Fri, 13 Jan 2006 12:13:11 +1100
Con Kolivas <kernel@kolivas.org> wrote:

> Can you try the following patch on 2.6.15 please? I'm interested in how
> adversely this affects interactive performance as well as whether it helps
> your test case.

"./a.out 5000 & ./a.out 5237 & ./a.out 5331 &"
"mount space/; sync; sleep 1; time dd if=space/bigfile of=/dev/null
bs=1M count=256; umount space/"

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5445 paolo     16   0  2396  288  228 R 34.8  0.1   0:05.84 a.out
 5446 paolo     15   0  2396  288  228 S 32.8  0.1   0:05.53 a.out
 5444 paolo     16   0  2392  288  228 R 31.3  0.1   0:05.99 a.out
 5443 paolo     16   0 10416 1104  848 R  0.2  0.2   0:00.01 top
 5451 paolo     15   0  4948 1468  372 D  0.2  0.3   0:00.01 dd

DD test takes ~20 s (instead of 8s).

As you can see DD priority is now very good (15) but it still suffers
because also my test programs get good priority (15/16).


Things are BETTER on the real test case (transcode): this is because
transcode usually gets priority 16 and "dd" gets 15... so dd is quite
happy.

BUT what is STRANGE is this: usually transcode is stuck to priority 16
using about 88% of the CPU, but sometimes (don't know how to reproduce
it) its priority grows up to 25 and then stay to 25.

When transcode priority is 25 the DD test is obviously happy: in
particular 2 things can happen (this is expected because I've observed
this thing before):

1) priority of transcode stay to 25 (when the file transcode is
reading from, through pipes, IS cached).

2) CPU usage and priority of transcode go down (the file transcode is
reading from ISN'T cached and DD massive disk usage interferes with
this reading). When DD finish trancode priority go back to 25.

-- 
	Paolo Ornati
	Linux 2.6.15-kolivasPatch on x86_64