Subject: Scheduler oddities
To: None <ross@netbsd.org>
From: Charles Hannum <abuse@spamalicious.com>
List: tech-kern
Date: 04/10/2002 00:52:01
So, following a discussion we had earlier, I note a few things:
1) The Alpha code divides the clock interrupt by 64 to call
schedclock() -- so it actually calls schedclock() at either 64Hz or
75Hz, depending on the model. According to your analysis, it
should be 16-20Hz.
2) The Alpha code is of course a special case, and does not help,
e.g., running a PC at 1000Hz. It also does not solve the problem
that other ports range from stathz=60 to stathz=512.
3) Assuming your algorithm were implemented correctly anyway, it means
that p_estcpu would only tick every 1/4 second. This is
unfortunate, in that it massively increases the ability (or just
random chance) of a process accumulating time without getting
nailed for it. This seems inappropriate and perhaps even a little
dangerous.
So, to fix problems 1 and 2, I would like to remove the Alpha hack,
and instead put code of this sort in statclock(), making schedhz a MI
constant:
static int schedtick;
...
if ((schedtick += schedhz) >= stathz) {
schedtick -= stathz;
schedclock(p);
}
In addition, I would like to get rid of spc_schedticks, and instead go
back to dividing p_estcpu by 4. However, I suggest doing this with a
global shift value, so that we can modify it based on schedhz and our
expected scheduler quantum. The p_estcpu bound can simply be
precalculated and stored in a global.
Does this sound sane? If so, I'll write code and send it here for
review.