Swapper question.

[John F. Haugh II]

In article <2688 at homxc.UUCP> dwc at homxc.UUCP (Malaclypse the Elder) writes:
>In article <4787 at killer.UUCP>, fmayhar at killer.UUCP (Frank Mayhar) writes:
>> I have a question, related to our development work on a 68020-based SVR2 system:
>> Why does swapper rack up so much CPU?
>
>                    what may be happening is that the system may
>at some time in the past have been swapping.

nope.  this has precious little to do with what is actually happening.
the following is how (in general terms) unix charges idle time to
process 0.  i seem to recall that this behaviour was introduced with
system 3.  this is just a general overview, obviously no one is going
to post system v sources for clock.c

clock() is called every HZ.  part of what is passed to clock()
is the program counter and program status word (flag and control word
or whatever) for the process which was interupted by the line or
real time clock.

for kernels with fixed address user pages (struct user), the variables
u.u_utime and u.u_stime are the cumulative user and system times for
the currently running process.  other kernels have different methods,
but in general this is how it is done.

if the kernel is idle, generally the pc is equal to some location where
the cpu either stops or loops.  way back when the address was idleloc
or something like that.  testing for ! USERMODE (ps) && pc == &idleloc
would then tell you if the CPU was idle (which is real handy for
updating the sysinfo structure).

so, the CPU times for an individual process can be handled with

	if (USERMODE (ps))
		u.u_utime++;
	else
		u.u_stime++;

or, if you don't want the swapper to get charged for idle time (which
is what I prefer), you can change the `else' to

	else if (pc != &idleloc)
		u.u_stime++;

or, should all else fail, the upage for process 0 is proc[0].u_addr,
modulo your software vendors sense of humor.  if clock() discovers
the machine is idle,

	proc[0].u_addr.u_stime++;

will also work Just Fine(tm).

the swapper does not actually ``run'' when it is idle.  it sleeps
on some address or another (i forget, runin, runout, runrun,
or for berkeley with long names runincirclesscreamandshout ;-))
it simple sleeps.  and whenever the kernel calls free() to deallocate
memory, the appropriate address is woken up.

- john.
-- 
John F. Haugh II                 +--------- Cute Chocolate Quote ---------
HASA, "S" Division               | "USENET should not be confused with
UUCP:   killer!rpp386!jfh        |  something that matters, like CHOCOLATE"
DOMAIN: jfh at rpp386.uucp          |             -- with my apologizes