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

Internet Message Format | 1992-12-30 | 5.2 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!gatech!concert!ais.com!bruce
From: [e-mail] (Bruce C. Wright)
Newsgroups: comp.os.os2.advocacy
Subject: Re: OS/2 bigot meets NT....
Message-ID: <[e-mail]>
Date: 30 Dec 92 01:37:31 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Applied Information Systems, Chapel Hill, NC
Lines: 85

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] (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.
>>
>>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?)

The problem can happen if you have several threads (either actual
process-level threads or threads within the OS itself) that all want
to allocate real memory at the same time -- say by paging in a portion
of their virtual address space.  The pager can only satisfy one of these
requests if there's free memory or if memory can be made free by having
its data paged out or otherwise released.  But if you're in a very low
memory situation, you may reach situations where there's nothing that
can be paged out -- maybe it's in use in some unpageable cache, or maybe
it's been locked down for an I/O buffer of some sort, etc.  The pager
may find that even though it has control of the CPU, there's nothing
useful it can do because all the resources are already spoken for.

It is often possible for a user to make such problems more likely by
mis-adjusting cache sizes (which may fatally reduce free memory).

This is all getting pretty far afield from the actual problem on a
real machine.

>>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.
>
> I myself still favor the bug theory, but it's an interesting debate.

I can't really say I can register a strong opinion on the exact cause
of what the original poster reported.  A bug would not be at all
surprising, but given that the machine was running on a fairly small (*)
amount of memory it may be just plain running out of resources,
especially if someone had increased cache values or list sizes beyond
what could be supported with the memory available.

Bruce C. Wright

(*) How soon we are jaded.  One of the main computers at one of my
first programming jobs had the princely sum of 4KW (8KB) of memory,
and took up as much space as a large desk, and we thought it was
a pretty nice machine at the time.  Now my PC has several times as
much main memory as the entire hard disk drive of that machine -- BCW