Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!uunet!sequent!muncher.sequent.com!news
From: vandys@sequent.com (Andrew Valencia)
Newsgroups: comp.unix.wizards
Subject: Re: Kernel Definition
Message-ID: <1991May23.170918.11612@sequent.com>
Date: 23 May 91 17:09:18 GMT
References: <1423@necis.UUCP>
Sender: news@sequent.com (News on Muncher)
Organization: Sequent Computer Systems, Inc.
Lines: 30

jjp@necis.UUCP (Jeff Phillips) writes:

>A friend of mine is writing a paper on balanced system approach.  In it he
>makes the assertion that "...(the UNIX operating system is) too large to fit 
>in system RAM all at once, therefore pieces of the operating system are swapped
>between system RAM and disk, thereby generating even more disk I/O requests."

Many people will tell you that the kernel is not paged or swapped to disk.
This is right so far as it goes, however there are certainly kernel data
structures which go out to disk and come back, and these definitely add
overhead.  In most UNIX implementations, the "u" area and the kernel stack
are swapped out along with the rest of a user process which is being swapped
out.  I believe the PTEs and DBDs from a Regions-based kernel are also swapped
out when the last in-core process referencing the particular region is
swapped out.  Similarly in BSD, the PTEs from a process are swapped out with
the process; the PTEs for a mapped file are swapped out when the last in-core
process is swapped which references that mapped file.

I agree that the UNIX OS is probably getting too large to fit in RAM all
at once.  I am not convinced that pageable kernels is the answer.  Different
organizations--especially microkernels--will probably become increasingly
important in the next 5 years.  "kernel" memory use is only one of many
issues which microkernels seem to address better than current UNIX technology.
But enough of the soap box....

I've pared the newsgroups line down to unix.wizards; I think that'll provide
more than adequate coverage for this topic.

					Andy Valencia
					vandys@sequent.com