lkml.org 
[lkml]   [1998]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH *] scheduler bigpatch (test results)
So, let me followup myself ...

On Wed, Oct 21, 1998 at 04:50:30PM +0200, Kurt Garloff wrote:
> This is rc5des416-linux-x86-mt. MT meaning multithreaded (on my UP machine...)
> If no other program competes with the idle rc5des, interactive performance
> is very very bad. After typing a character at the bash, it takes one second
> for it to appear!

I found an even much worse situation: I recompile my kernel (make zlilo).
Everything is up to date. When I do it for the second time, everything is in
the buffer cache, so it's pretty fast. User and System times are always the
same (59.9s user + 4.6s system on my 6x86-P200+ w/ 64MB), but the the real
differs a lot.
Without rc5des : 1:08.4s
w/ rc5des, nice19 : 1:12.8s
w/ rc5des idle (499) : 4:19.6s !!!!

(And on my system I set HZ to 200. With HZ == 100, it imagine the situation
to be worse.)

We certainly don't want a kernel compile with an idle process in the
background to be slower than with a niced(19) process.

The reason I imagine for this slow compilation is that make is sleeping and
waiting for another make or bash or ... which is added to the runqueue on
every directory. rc5des is running and the newly created processes only get
the CPU after the long timslice of rc5des is over.

> Whenever an "idle" task is on the top of the runqueue, it takes quite some
> time to have it removed and have an "other" task waked.
> (I think, it's because its on the fifo queue and we don't recalculate
> priorities very often then.)
>
> So, the idle policy is either meant to act like that (unlikely, because most
> peolpe wanting to have it, want to use rc5des or cracker) or something is
> wrong with it.
> If the first is true, we still need some implementation of very nice, like
> getting 0.05% of CPU against a nice 0 process instead of 5%. The advantage
> is having it react to kill -15 (even if an other process is running) after
> some time.

Looking at your code, I think you did mean it: sched.c:581:
else /* SCHED_IDLE, long slices */
p->counter += 499;

I changed this value from 499 to 25, and now I am satisfied with the
interactive performance as well as woth my kernel compilation benchmark.
(Patch is appended. Please consider applying it to your patch. Maybe you
find a better solution, but I think you would have to create a third queue
for it.)
Kernel compilation now is:

w/ rc5des idle (25) : 1:09.3s

Another detail:
I reported the two rc5des which are normally only sleeping were not shown in
S state by ps. They are back to S now. Strange. (Why?)

BTW: The RT priority queue is doing what it's expected to, now. RGooch's
little program to measure scheduler latency now shows the same times
regardless of how many other processes are running.

Regards,
--
Kurt Garloff <K.Garloff@ping.de> (Dortmund, FRG)
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff
Unix IS user friendly - it's just selective about who its friends are!
--- linux/kernel/sched.c~ Wed Oct 21 18:06:28 1998
+++ linux/kernel/sched.c Wed Oct 21 17:42:36 1998
@@ -579,7 +579,7 @@
if (p->policy == SCHED_OTHER)
p->counter += p->priority;
else /* SCHED_IDLE, long slices */
- p->counter += 499;
+ p->counter += 25;
p = p->next_run;
}
read_unlock(&tasklist_lock);
\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.065 / U:1.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site