> On Tue, 20 Jul 1999, Stephen C. Tweedie wrote:
>
> [good explanation of VMS behaviour]
>
> Does the "working set" specify the pages in physical RAM or the
> pages of total virtual memory (RAM + swap) used?
>
Working set is virtual. There is no notion of 'swap' known to a process.
However there is the notion of "page-fault rate" so it's obvious that
faulting will occur. Also, virtual RAM could not exceed (real RAM -
kernel resident pages needed + the size of the page file). There was
no notion of 'over commit'. As processes used up virtual RAM, they
might be swapped out to the swap file to free up some pages if they
were sleeping. Since pages in early VAXen were small (512 bytes), it
was important to keep a 'virtual' page of zeroed RAM available. This
same page was marked 'read-only' and was shared by all processes that
had data buffers that were not written yet. Such 'demand-zero' paging
allowed some of the same behavior that you now get from 'over commit'.
The VAXen hardware required that this physical page actually exist so
you'd get the right kind of trap, i.e., not a machine-check as a result
of an access to non existent RAM. Modern processors can mark pages
in descriptors so a physical access doesn't have to be made to generate
a page fault.
One thing that helps(ed) VAX/VMS is that the kernel has many aspects of a
process. In other words, the WSMAX, WSMIN, NPAGEDYN, etc., can be set
separately for the kernel. This has some drawbacks since a call for system
services does not execute in the context of the current process (as in
Unix). However, it allows the kernel to survive any user-mode attempts to
kill it.
> (My 'typical' OOM situation is one where all virtual memory is full,
> i.e. paging out to the swap partitions cannot help since they are
> full.)
Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/