fmayhar@killer.UUCP (Frank Mayhar) (07/13/88)
I have a question, related to our development work on a 68020-based SVR2 system:
Why does swapper rack up so much CPU? In spite of the fact that the machine is
completely idle for days at a time, swapper's CPU stays roughly even with the
amount of time that the system has been up, to within about a minute. What
gives, and how can we change this? The machine will run as an intelligent
peripheral for a mainframe, and we're trying to maximize performance. If anyone
can help, please reply by email to the Internet address if possible, otherwise
to this machine.
Thanks in advance.
--
Frank Mayhar UUCP: ..!{ihnp4,dj3b1}!killer!fmayhar
ARPA: Frank-Mayhar%ladc@BCO-MULTICS.ARPA
USmail: 2116 Nelson Ave. Apt A, Redondo Beach, CA 90278
Phone: (213) 371-3979 (home) (213) 216-6241 (work)dwc@homxc.UUCP (Malaclypse the Elder) (07/14/88)
In article <4787@killer.UUCP>, fmayhar@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? In spite of the fact that the machine is > completely idle for days at a time, swapper's CPU stays roughly even with the > amount of time that the system has been up, to within about a minute. What > gives, and how can we change this? The machine will run as an intelligent > peripheral for a mainframe, and we're trying to maximize performance. If anyone > can help, please reply by email to the Internet address if possible, otherwise > to this machine. > i never get mail to work when the path is longer than 5 sites so i decided to post. what may be happening is that the system may at some time in the past have been swapping. the swapper may have swapped out a sleeping process (say a user level daemon) during that period. that process will never be brought in again until it wakes up. but if there is a process that is swapped out, the swapper remains in a mode of checking to see if anyone is eligible to come in -- every second. if there was no one swapped out, the swapper would go to sleep until a memory condition wakes it up (i.e. swapper doesn't use up cpu in this case). one thing you could do is use something like crash to see if there are any processes that are sleeping and swapped out (does ps give this info?--i forget). if it is indeed a daemon process, often times you can just kill it and restart it again. now if there is indeed plenty of memory, it will remain in core and the swapper can sleep an easy sleep instead of the restless sleep. danny chen ihnp4!homxc!dwc
shz@packard.UUCP (S. Zirin) (07/15/88)
In article <4787@killer.UUCP>, fmayhar@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? In spite of the fact that the machine is > completely idle for days at a time, swapper's CPU stays roughly even with the > amount of time that the system has been up, to within about a minute. What > gives, and how can we change this? The machine will run as an intelligent > peripheral for a mainframe, and we're trying to maximize performance. There are several ports of the UNIX Operating System that incorrectly attribute clock ticks during the idle loop to the swapper (PID 0). The sar(1) command on these systems usually shows zero idle time with a very high number in the "sys" column. A peek at the os/clock.c source module will tell you for sure. Seth Zirin att!packard!shz
jfh@rpp386.UUCP (John F. Haugh II) (07/15/88)
In article <2688@homxc.UUCP> dwc@homxc.UUCP (Malaclypse the Elder) writes: >In article <4787@killer.UUCP>, fmayhar@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@rpp386.uucp | -- with my apologizes
fmayhar@killer.DALLAS.TX.US (Frank Mayhar) (07/18/88)
In article <3977@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes: >In article <2688@homxc.UUCP> dwc@homxc.UUCP (Malaclypse the Elder) writes: >>In article <4787@killer.UUCP>, fmayhar@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. >[description of Unix idle time accounting omitted] >John F. Haugh II Hmmmmm. VERy interesting. Considering this project is for a very sensitive customer, it looks like it's time to hack the source. (Fortunately we have that option.) On a more general note: Many, many thanks to those that responded to my question. I'm glad to learn that my concern was groundless. (And I get to learn a little more about the Unix kernel, which is always nice.) Happy hacking, kernel-wise! -- Frank Mayhar UUCP: ..!{ihnp4,dj3b1}!killer!fmayhar ARPA: Frank-Mayhar%ladc@BCO-MULTICS.ARPA USmail: 2116 Nelson Ave. Apt A, Redondo Beach, CA 90278 Phone: (213) 371-3979 (home) (213) 216-6241 (work)
tes@pyr.gatech.EDU (TOM SEXTON) (07/24/88)
Help please,
Does anyone know which global variable on Berkley 4.3 to change in order
to change the color(black/white) of the cursor? Or if anyone has any
experience with the 'curses' package, what can be done in that case? Any
info on how to either change color or font of cursor would be greatly
appreciated.
Thanks ahead of time,
Tom