NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/os2/advocacy/11103

Text File | 1992-12-29 | 5.1 KB | 100 lines

Newsgroups: comp.os.os2.advocacy
Path: sparky!uunet!grebyn!daily!mfraioli
From: [e-mail] (Marc Fraioli)
Subject: Re: OS/2 bigot meets NT....
Message-ID: <[e-mail]>
Organization: Grebyn Timesharing
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 29 Dec 1992 21:52:19 GMT
Lines: 89

In article <[e-mail]> [e-mail] (Bruce C. Wright) writes:
>In article <[e-mail]>, [e-mail] (Marc Fraioli) writes:
>> In article <[e-mail]> [e-mail] (Bruce C. Wright) writes:
>>>In article <[e-mail]>, [e-mail] (Joseph C. Pallante) writes:
>>>> I have a question....
>>>>
>>>> All this debate is over:  Many, Many crashes because a PC has only
>>>> 8 megs of RAM.
>>>>
>>>> My question:  Why does NT crash (or OS/2 for that matter) because of lack
>>>> of enough RAM?  I would expect it to be slow because the OS would have
>>>> to manipulate the memory, do some swapping, etc...   But, if it follows
>>>> all the rules it should, theoreticaly, it should not crash.  It should
>>>> just take longer to do its job, due to the overhead of running on
>>>> a machine with little memory.
>>>
>>>Even on a virtual memory system, the system still needs a certain amount
>>>of real memory in order to run itself, map I/O buffers, and keep track of
>>>virtual memory, etc.  If the system is sufficiently overcommited on memory,
>>>it may not be able to do all these things with available memory and in
>>>fact may encounter situations where every process within the system is
>>>waiting for memory currently in use by another process to be freed.
>>>
>> I thought that for this reason, the kernel of the OS is not made to be
>> swappable, and runs at the highest possible priority, a priority that no
>> other process can have.  This way, the system should always be able to
>> recover.
>
>I don't particularly like the term `swappable' when applied to an OS
>kernel -- to me it implies that the entire kernel might be moved out
>to disk, which makes no sense.  `Pageable' makes more sense, at least
>when talking about some parts of the kernel.  (I've usually seen the
>term `swap' to mean that the entire memory-resident portion of the
>process or object gets written to page or swap files, and `page' to
>mean that only certain sections [pages] get written to the pagefile).
>
Ok, I played it a little loose with my terminology.  If you look a
little lower down you will see I later used the word "pageable" as well.
Sorry, I'll try to be more careful in the future.

>Where I think there's a flaw in your reasoning is in assuming that
>the `OS kernel' == `OS as a whole'.  Large operating systems are often
>broken up internally into a number of pieces;  the file system code,
>for example, really doesn't have to be permanently resident in its
>entirety.  You just need enough of the device-level code to be resident
>for the system to load the higher-level file system code.  GUIs are
>also candidtates for being moved out to disk in low memory situations.
>Even some portions of the kernel itself might be pageable -- it depends
>on what contexts in which you could stand to incur a page fault and call
>the disk driver, which is going to be dependent on the OS internal
>architecture.
>
But if the 'critical' routines in the kernel, such as the pager, are not
pre-emptable and non-pageable, shouldn't they always be present to
resolve such conflicts (assuming of course that you have enough memory
to load the critical portion of the kernel-- /vmunix on a VIC-20?  I
didn't think so.  So what'd I buy that 16k RAM expansion cartridge for?)

>> I just remember IBM making a big deal out of the fact
>> that it's AIX 3.1 (I think that's the right version #) kernel was
>> actually pageable-- the implication being that most aren't.
>
>Probably many aren't, but it's not uncommon.  That sounds like it was
>probably typical marketing hype.  Note that there has to be at least a
>minimal part of the kernel that isn't pageable -- the part that handles
>page faults (!) and that handles low-level reads and writes to the disk
>(to be able to do something with the page faults when they occur).
>
Makes sense.

>Now I should say that I don't _know_ that this is what is happening
>to those people who have reported system lockups/crashes under low
>memory conditions -- it's also possible that there's a bug somewhere.
>But I think that as far as it goes it's an accurate description of
>what _can_ happen in such systems.  One thing you have to keep in mind
>is that when a large system like that `runs in 4MB', it doesn't mean
>that there are 4MB of virtual memory used by the OS and its system-
>level processes, but that there are 4MB of real memory required to
>properly deal with the much larger virtual address space in use by
>the OS in all its pieces.  Running it in a lot less can cause all
>sorts of strange behavior, depending on what runs out first.
>
I myself still favor the bug theory, but it's an interesting debate.

>Bruce C. Wright

--
Marc Fraioli
[e-mail]                (So I'm a minimalist...)