jdp@PacBell.COM (Jerry D. Pierce) (02/11/90)
I am running Interactive 2.0.2 on a Wyse 386/25 machine with 4 megs of memory. During a recent compile of GCC, the machine had to go out and swap processes to the swap area on the disk. A swap -l showed that we were into the disk swap area for about 150 blocks. Three days after the compile completed, we were STILL in the disk swap space for 120 blocks or so. killing the gettys on both of the virtual terminals regained xx blocks. Killing and restarting the lpsched daemon managed to regain all of the blocks except for 8. Short of rebooting, how do I get those other unknown processes back into main memory? And should I really care about being out in swap?? And aren't processes supposed to go back into main memory when there is sufficient space available? Jerry Pierce pacbell!pbhyf!jdp
neese@adaptex.UUCP (02/15/90)
>I am running Interactive 2.0.2 on a Wyse 386/25 machine with 4 >megs of memory. During a recent compile of GCC, the machine had to >go out and swap processes to the swap area on the disk. > >A swap -l showed that we were into the disk swap area for about >150 blocks. Three days after the compile completed, we were >STILL in the disk swap space for 120 blocks or so. killing >the gettys on both of the virtual terminals regained xx blocks. >Killing and restarting the lpsched daemon managed to regain all >of the blocks except for 8. > >Short of rebooting, how do I get those other unknown processes back >into main memory? And should I really care about being out in swap?? You shouldn't really care. >And aren't processes supposed to go back into main memory when there >is sufficient space available? Theoritically, processes that have been swapped out of main memory will be swapped back in once they are needed by the system, and if there is enough memory for them to be swapped back in at the time they are needed. You can test this by executing a print job, which should cause the lp daemon to be swapped back into main memeory if there is enough memory for this, you can so the same thing for the gettys, have any inactive ttys login and the gettys should be swapped back in; again if there is enough memory. If the processes are not needed, then they will stay on the swapper until needed, so you should not worry about it. Roy Neese Adaptec Central Field Applications Engineer UUCP @ {texbell,attctc}!cpe!adaptex!neese merch!adaptex!neese uunet!swbatl!texbell!merch!adaptex!neese
cpcahil@virtech.uucp (Conor P. Cahill) (02/18/90)
>>Short of rebooting, how do I get those other unknown processes back >>into main memory? And should I really care about being out in swap?? > >You shouldn't really care. Ditto. One of the places where you can get program placed onto the swap device when they aren't being run by anybody anymore is if the program has the sticky bit set (a 't' in the others-execute slot on an ls -l listing, set by doing a chmod 1xxx on the file). If this is set the text portion of the program will remain in memory (and be swapped out to the swap device if they are no longer needed and the memory is needed for other stuff, never to be swapped in until they are needed). You shouldn't worry about them. You can get rid of them by chmoding the file, removing the file, writing to the file, or umounting the file system that the file is on. Note that none of these will work if someone is running the program. (of course it normally won't be on the swap device at that time). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
tneff@bfmny0.UU.NET (Tom Neff) (02/18/90)
In article <1990Feb17.203445.12673@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > One of the places where you can get program placed onto the >swap device when they aren't being run by anybody anymore is if the program >has the sticky bit set (a 't' in the others-execute slot on an ls -l >listing, set by doing a chmod 1xxx on the file). On SV3.2 versions I've seen, you can also say chmod +t filename and set the sticky (text) bit. You must be super-user. >If this is set the >text portion of the program will remain in memory (and be swapped out >to the swap device if they are no longer needed and the memory is needed >for other stuff, never to be swapped in until they are needed). Right, and the text bit is a great feature if you don't overuse it. It scores the biggest win on largish executables which you do have frequent occasion to use interactively, like vi, less, mush, or perl. The normal latency hit of loading these big fellows is eliminated! For perl especially, the difference is enormous. Setting sticky on that utility basically saved it from uselessness at my site. But the price is that everything sticky you load STAYS in memory (or the swap area) until you remove it or reboot. So you're cutting into your cache. It's a good idea to increase NBUFS and rebuild the kernel to match your typical load of sticky programs, otherwise your cache hit rate goes down noticeably. So basically you can ask, Do I love utility X enough to want to spend the RAM to keep it resident all the time barring swaps? If YES, set it sticky. (Vi and less are natural candidates.) If NO, don't bother.