Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!gem.mps.ohio-state.edu!apple!bbn!news From: news@bbn.COM (News system owner ID) Newsgroups: comp.unix.wizards Subject: Re: What SHOULD go in the kernel Message-ID: <47211@bbn.COM> Date: 20 Oct 89 22:00:35 GMT References: <2186@ektools.UUCP> <47040@bbn.COM> <17166@rpp386.cactus.org> Reply-To: pplacewa@capella.bbn.com (Paul W. Placeway) Distribution: na Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 30 jfh@rpp386.cactus.org (John F. Haugh II) writes: < The primary restriction against a paging kernel is keeping the < paging code from being paged ;-). After that, satisfying real-time < constraints, etc. will yield a collection of pages which must < be locked in memory as well. What should be left in the list < of locked pages should only be lower halves of device drivers, < the VM manager, the pager, and the global data required by those. < < Massive tables, seldom used device drivers, and one-time < initialization code should all be candidates for the pager. < I paid for the memory, and damnit, I want to use it. Actually, I guess there are two ways of looking at this. The first is you want your kernel to stay up even if your swap device fails. If true, then there is obviously no way to let part of your kernel swap out. On the other hand, if you consider the machine dead when a swap device dies, then swapping out the kernel is fair enough. If your kernel could do this, then demand-loadable device drivers would be less needed (although still nice to have for other good reasons). As John indicates, a kernel that ran this way would probably be much more memory efficient (not a bad thing, considering some of todays kernels). A sort of work-around for this is to have a bunch of user-level kernel processes that do most of the work (like tty processing), and let them get paged and swapped out when not in use. This is even a performance win for some things (tty drivers, among others). -- Paul