From:	MERC::"uunet!WKUVX1.BITNET!MacroMan" 22-JUL-1992 10:08:55.01
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	VMS Memory Management/PGFLQUOTA question

OK, I have a question for all you VMS memory management types out there:

What I would like to do is reserve a large (VERY large) segment of virtual
address space for my exclusive use in an image.  We're talking a quarter of a
gigabyte or so here.

If possible, I would like to simply reserve this address range without actually
creating pages in it, since then I won't need to have a humongous page file
quota.  I will have to jack VIRTUALPAGECNT way up since my page tables will
have to be large enough so that I can create pages within the range as I wish,
but I can live with that.

Now, as far as I can tell, when I issue an $EXPREG to create some virtual
memory in P0, the system service looks at PCB$L_FREP0VA to see where it can
create the virtual memory.  This suggests that a way to reserve space is to
look at FREP0VA, add the amount of memory I want to allocate to that address,
and then create ONE PAGE just beyond that. This will cause my page table to be
expanded, and will force FREP0VA past that one page, thus reserving the desired
address range.  I can then create/delete memory within that address space at
will (using $CRETVA with specific addresses), without worrying that any other
well-behaved facility (such as LIB$GET_VM or anything else that calls $EXPREG)
will go and create pages in there.

In theory this looks good to me.  In practice, however, I am clearly assuming
that the rest of the system is well-behaved in that it won't create memory
based anywhere other than beyond where FREP0VA points.  Also, I am assuming
that $EXPREG's ONLY look at FREP0VA and won't do some kind of best fit on holes
in the page table space on subsequent calls.

My question for y'all then, is how does this strike you?  Is this an accident
waiting to happen?  Do any of you know of any facility which is not
well-behaved in this respect? Is VMS/ALPHA likely to completely screw me in the
future, or what?  Thoughts?  Comments?

If this doesn't seem like a good idea, the obvious other approach is to simply
create all the memory I need.  This will require a huge page file quota (though
not real page file space, since I don't expect to be touching many of these
pages), so I'm wondering what the real costs of increasing page file quota are?
Do any process/system data structures have sizes based on PGFLQUOTA, for
example?

And here's a gross idea.  Suppose instead of requiring any process doing this
to have a huge page file quota, I wrote a user system service or something to
temporarily bump up the page file quota, do the create, then drop the quota
back down.

Is remaining page file quota synched to any data structures that the system
might later notice are inconsistent?  Will this bite me later when some system
component notices that I seem to have more pages than page file quota, or is
PGFLQUOTA just a value like BYTELM, that simply gets added and subtracted from?
(i.e., whose ONLY purpose is to control how much of a resource you can snag?)

Any thoughts on any or all of this would be most welcome.  Thanks!

- John W. Manly  <JWMANLY@AMHERST.EDU>  (System Manager -- Amherst College)