WAS: [SCHED] Totally WRONG prority calculation with specific test-case
(since 2.6.10-bk12)
http://lkml.org/lkml/2005/12/27/114/index.html
On Wed, 28 Dec 2005 10:26:58 +1100
Con Kolivas <[email protected]> wrote:
> The issue is that the scheduler interactivity estimator is a state machine and
> can be fooled to some degree, and a cpu intensive task that just happens to
> sleep a little bit gets significantly better priority than one that is fully
> cpu bound all the time. Reverting that change is not a solution because it
> can still be fooled by the same process sleeping lots for a few seconds or so
> at startup and then changing to the cpu mostly-sleeping slightly behaviour.
> This "fluctuating" behaviour is in my opinion worse which is why I removed
> it.
Trying to find a "as simple as possible" test case for this problem
(that I consider a BUG in priority calculation) I've come up with this
very simple program:
------ sched_fooler.c -------------------------------
#include <stdlib.h>
#include <unistd.h>
static void burn_cpu(unsigned int x)
{
static char buf[1024];
int i;
for (i=0; i < x; ++i)
buf[i%sizeof(buf)] = (x-i)*3;
}
int main(int argc, char **argv)
{
unsigned long burn;
if (argc != 2)
return 1;
burn = (unsigned long)atoi(argv[1]);
while(1) {
burn_cpu(burn*1000);
usleep(1);
}
return 0;
}
----------------------------------------------
paolo@tux ~/tmp/sched_fooler $ gcc sched_fooler.c
paolo@tux ~/tmp/sched_fooler $ ./a.out 5000
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5633 paolo 15 0 2392 320 252 S 77.7 0.1 0:18.84 a.out
5225 root 15 0 169m 19m 2956 S 2.0 3.9 0:13.17 X
5307 paolo 15 0 100m 22m 13m S 2.0 4.4 0:04.32 kicker
paolo@tux ~/tmp/sched_fooler $ ./a.out 10000
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5637 paolo 16 0 2396 320 252 R 87.4 0.1 0:13.38 a.out
5312 paolo 16 0 86636 22m 15m R 0.1 4.5 0:02.02 konsole
1 root 16 0 2552 560 468 S 0.0 0.1 0:00.71 init
If I only run 2 of these together the system becomes everything but
interactive ;)
./a.out 10000 & ./a.out 4000
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5714 paolo 15 0 2392 320 252 S 59.2 0.1 0:12.28 a.out
5713 paolo 16 0 2396 320 252 S 37.1 0.1 0:07.63 a.out
DD TEST: the usual DD test (to read 128 MB from a non-cached file =
disk bounded) says everything, numbers with 2.6.15-rc7:
paolo@tux /mnt $ mount space/; time dd if=space/bigfile of=/dev/null bs=1M count=128; umount space/
128+0 records in
128+0 records out
real 0m4.052s
user 0m0.004s
sys 0m0.180s
START 2 OF THEM "./a.out 10000 & ./a.out 4000"
paolo@tux /mnt $ mount space/; time dd if=space/bigfile of=/dev/null bs=1M count=128; umount space/
128+0 records in
128+0 records out
real 2m4.578s
user 0m0.000s
sys 0m0.244s
This does't surprise me anymore, since DD gets priority 18 and these
two CPU eaters get 15/16.
As usual "nicksched" is NOT affected at all, IOW it gives to these CPU
eaters the priority that they deserve.
--
Paolo Ornati
Linux 2.6.15-rc7-g3603bc8d on x86_64
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
