[Info-vax] Process memory settings

[jbriggs444]

On Aug 19, 6:29 pm, Neil Rieck <n.ri... at sympatico.ca> wrote:
> On Aug 17, 8:58 am, "Syltrem" <syltremz... at videotron.ca> wrote:
>
> > "David J Dachtera" <djesys... at spam.comcast.net> wrote in messagenews:4A8770D7.F48BDBEC at spam.comcast.net...
>
> > > What is the value of WSMAX?
>
> > > D.J.D.
>
> > Parameter Name            Current    Default     Min.       Max.   Unit
> > Dynamic
> > --------------            -------    -------   -------    -------  ----  -------
> > WSMAX                     1421312       8192      1024  134217728 Pagelets
> >  internal value             88832        512        64    8388608 Pages
>
> This value seems high enough to me but as most people here already
> know, each process is allocated a certain amount of resources via
> SYSUAF at process creation and WSMAX is the ultimate upper limit.

Ultimate upper limit for the working set.  i.e. physical memory for a
particular process.

> Now
> we need to know what the UAF settings are of the person running the
> compiler. For example, here is what I use on my AS-4100 to run a BASIC
> compiler on a 50k monster source file:
>
> Maxjobs:         0  Fillm:       300  Bytlm:      2000000
> Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
> Maxdetach:       0  BIOlm:      1024  JTquota:       8192
> Prclm:          20  DIOlm:      1024  WSdef:         2000
> Prio:            4  ASTlm:       100  WSquo:        20000
> Queprio:         0  TQElm:        10  WSextent:    200000
> CPU:        (none)  Enqlm:      2000  Pgflquo:    2000000
>
> IIRC, WSquo is the number of pages we guarantee (so you could trash
> with other processes if memory was tight) but this process is allowed
> to borrow unused resources (if they are available) from other users up
> to WSext.

Right.  Sysgen parameters "growlim", "borrowlim" and "wsinc" come into
play here if memory serves.  You start at WSdefault.  Automatic
working set adjustment will proceed to WSquota if memory is not
scarce.  It will then proceed to WSextent if memory is plentiful.
Swapper trimming, swap-out and image exit are the flip side of the
coin.  They trim back working set from a process that has grown.
Automatic working set reduction is normally disabled by leaving
"wsdec" at its default of zero.

Again, this is relevant to physical memory assigned to the process
working set.  It is irrelevant as concerns virtual memory

> Also, it is a good idea to have a huge value for Pgflquo so
> it can be used to support your balance-set.

pgflquota does not support the balance set.  It is difficult to
decipher what you are trying to say here.  The "balance set" is the
set of processes that are not swapped out.  On VAX this had
implications for virtualpagecnt since the process page table lives in
the process header, the process header is mapped in S0 virtual address
space and all non-swapped-out processes need their process header to
be resident in S0.  On VAX, the process page table size was determined
statically based on virtualpagecnt.  The size of the process header
and, as a result, the number of headers that could fit into the
balance set was determined in part by virtualpagecnt.

A huge pgflquota backed up by a huge virtualpagecnt would force you to
limit your balance set on VAX.  [By VAX standards, 1 gig was "huge"]

wsmax and procsectcnt have (or had) a similar interaction with
balsetcnt.  The process section table and the working set list (the
table that keeps track of the working set) live in the same memory
block.  The one grows from the bottom up and the other grows from the
top down.  The memory block is statically sized based on the
[weighted] sum of wsmax and procsectcnt.  This block lives in the
process header.

As has been revealed upthread, the end user in this case is up against
a P0/P1 address space limit.  He's got around a gig of P0 virtual
address space and that's an architectural limit on what a 32 bit app
can use.  John Reagan had suggested this diagnosis early on.  When the
numbers came in, it was pretty well confirmed.