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.