![]() | |||||||||||||
Messages in this thread |
At 09:00 PM 1/9/2006 +0100, Paolo Ornati wrote:
>On Mon, 09 Jan 2006 16:52:17 +0100
>Mike Galbraith <efault@gmx.de> wrote:
>
> > >Care to try an experiment?...
>
>Yes.
Thanks.
>With my simple proggy things improve a bit:
<snip rest of good news>
>BUT if I start more of them (3/4) I'm able to fool it.
>
>"./a.out 7000 & ./a.out 6537 & ./a.out 6347 & ./a.out 5873"
>
>2 TOP's snapshots:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 5625 paolo 17 0 2392 288 228 R 31.6 0.1 0:10.74 a.out
> 5626 paolo 17 0 2392 288 228 R 28.8 0.1 0:09.16 a.out
> 5627 paolo 17 0 2392 288 228 R 22.2 0.1 0:07.59 a.out
> 5624 paolo 17 0 2392 288 228 R 17.4 0.1 0:08.67 a.out
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 5626 paolo 16 0 2392 288 228 R 30.1 0.1 0:39.95 a.out
> 5627 paolo 16 0 2392 288 228 R 24.1 0.1 0:34.93 a.out
> 5625 paolo 18 0 2392 288 228 R 23.5 0.1 0:37.53 a.out
> 5624 paolo 18 0 2392 288 228 R 21.9 0.1 0:37.60 a.out
> 5193 root 15 0 167m 17m 2916 S 0.2 3.5 0:09.67 X
> 5638 paolo 18 0 4952 1468 372 R 0.2 0.3 0:00.15 dd
>
>DD test (256MB): real 3m37.122s (instead of 8s)
Ok, I'll take another look. Those should be being throttled.
>REAL LIFE TEST (transcode)
>
>While running only transcode it gets priority 25:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 5857 paolo 25 0 114m 18m 2424 R 90.9 3.7 0:14.28 transcode
> 5873 paolo 19 0 49860 4452 1860 S 8.6 0.9 0:01.40 tcdecode
> 5308 paolo 16 0 86796 22m 15m R 0.2 4.4 0:06.26 konsole
> 5687 paolo 16 0 98648 37m 9348 S 0.2 7.5 0:02.11 perl
> 5872 paolo 24 0 21864 1064 600 S 0.2 0.2 0:00.01 tcextract
>
>
>But if I run also the DD test, "transcode" priority start fluctuating
>and can go down to 18/19 (from time to time) interfering with DD:
19 shouldn't interfere from the cpu side, but 18 will.
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 5694 paolo 19 0 114m 18m 2424 R 75.1 3.7 0:42.29 transcode
> 5710 paolo 25 0 49856 4452 1860 R 8.0 0.9 0:04.36 tcdecode
> 5726 paolo 18 0 4952 1468 372 R 4.0 0.3 0:00.77 dd
>
>
>This seems to happen because also transcode is reading (not directly but
>through pipes) from disk so the massive disk usage of DD interferes
>with it, this leads to transcode using less CPU and getting better
>priority.
It can't be pipe waits, they're disabled in the kernel. Most likely the
credit we get for being activated without having yet been selected.
>The exact behaviour changes time to time... but seems to confirm my
>teory.
>
>I don't know how can "nicksched" keep transcode priority always to 40
>even when I'm running the DD test... I should retry and see.
>
>
>PS: yes, transcode is reading from disk, but SLOWLY... i think that a
>good read-ahead should fullfill his needs even when doing the HD
>stressing DD test, no?
Dunno.
-Mike
-
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/
| ||||||||||||
| Last update: 2006-01-10 08:11 [from the cache] ©2003-2008 | |||||||||||||