Re: Basic virtual memory question
From: Bob Koehler (koehler_at_eisner.nospam.encompasserve.org)
Date: 01/07/05
- Next message: JF Mezei: "Re: Basic virtual memory question"
- Previous message: Warren Spencer: "Anyone have Sybase V10 'cpre' for OpenVMS Alpha?"
- In reply to: JF Mezei: "Re: Basic virtual memory question"
- Next in thread: JF Mezei: "Re: Basic virtual memory question"
- Reply: JF Mezei: "Re: Basic virtual memory question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Jan 2005 15:55:36 -0600
In article <1105130148.f8b79f6159b319c32dfc5320f50ffd8c@teranews>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
> Bob Koehler wrote:
>
>> At the SYSGEN level things are limited by VIRTUALPAGECNT and WSMAX.
>
> SYSGEN's help tells me that VirtualPageCnt has been obsolete since version 7.0.
>
> What prevents me from giving a 200 meg PGFILQUO to a username and have a
> process created that then does a MALLOC of 200 megabytes on a 16 meg Microvax
> II ?
MALLOC'ed pages are in the working set and therefor limitted by the
working set parameters.
>
> Ok, so each process has its own page table then ?
Yes, in the process header in P1 space up to (I think) VMS 7.1.
Now I think Alphas (and IA64s) can keep it in S2 space, but it's
still a per-process data structure.
> How does VMS size that page table ? (seems it used to be VIRTUALPAGCNT that
> answered that question, but is now obsolete).
Since my internals manual is pre VMS 7.0, I don't know that one. I
think since VIRTUALPAGCNT was eliminated there is some capacity to
resize the map. I think the map sizes are derived from the working
set sizes.
>> PAGEDYN and NPAGEDYN limit kernel memory pools, not process memory.
>
> Howeber, any physical memory that is alloacted to system structures is memory
> that cannot be used by processes to map their virtual pages to physical pages,
> correct ?
Processes do map system structures, they have to since they can call
routines in the kernel and those routines must be able to manipulate that
data. (A lot of those routines change to privileged mode but very
few execute outside of process context, and even then some process
is current so the system space map is valid). Actually all processes
map system space via a shared map. (The map is multi-level, the lower
levels of system space maps only actually exist once).
>> No. There is a parameter PHYSICALPAGES which can be set to prevent
>> VMS from mapping pages that look like RAM but are not actually memory,
>
> I thought PHYSICAL PAGES was to simulate a system with less memory that it
> really has.
That's another valid use. But it used to be used to keep VMS from
mapping UNIBUS addresses on VAX-11 series systems which had
peripherals that looked like RAM (VMS had to be able to map UNIBUS
RAM in order to support VAX 11/730 and 725). I think some Qbus
systems had the same issue. Other systems generally had RAM and
peripherals on different busses.
>> No process or combination of processes should be limited to the
>> physical RAM size of the computer in any virtual memory OS.
>
> yes, but what determines the virtual memory limit a process can think it has
> access to ? If I give it a PAGFILQUO of 200 megs, (and there is 200 megs
> available in the page file), is there another parameter that woudl prevent the
> procesxs from using 200 megs ?
You'ld have to give it the required working set quota and make sure
WSMAX was at least as big. Then the process could map 200MB even if
the pagefile free space was less than 200MB. You can over-commit
page files. Just never let the pagefile run out of free space
(i.e. actually page out too much). For example, I routinely keep
my page files about 25% free and use the negative "reservable" value
as an estimate of how much to grow them when they get below 25% free.
By comparison, we routinely ran 3MB programs on a 1MB VAX 11/780
and 20MB programs on 4MB VAXen. VMS is capable of running 200MB
program on 16MB VAXen (I probably had some like that when I was
developing X11 based user interfaces).
- Next message: JF Mezei: "Re: Basic virtual memory question"
- Previous message: Warren Spencer: "Anyone have Sybase V10 'cpre' for OpenVMS Alpha?"
- In reply to: JF Mezei: "Re: Basic virtual memory question"
- Next in thread: JF Mezei: "Re: Basic virtual memory question"
- Reply: JF Mezei: "Re: Basic virtual memory question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|