info-vax@ucbvax.ARPA (03/06/85)
From: *Hobbit* <AWalker@RUTGERS.ARPA> I just brought up and tuned a 785 with 12Mb of memory. I claim that if I tweak it correctly, I should be able to do things and not have it page at all, if I'm the only person logged in [which has so far been the case]. No funny servers are running; just OPCOM and ERRFMT and me. Yet I rack up page faults at a respectable rate. My process working set is plenty big enough to do what I've been doing. I would think that my process, the few others laying around, and the system image should easily all fit into 12 meg. Am I right in assuming that there is a way to completely eliminate paging, given ideal conditions [like lots of physical memory]? If so, what are some example things I can do in SYSGEN to make it happen? Aside: If you have just disconnected from a virtual terminal, and you had set your UIC to something different for that process, you must set your UIC to that other one when you log in again before you can connect to the VT. It doesn't matter how many *privs* you have turned on, your UIC must match. Just something I found out while wondering where this random ss$_nopriv came from... _H* -------
rcb@rti-sel.UUCP (Random) (03/06/85)
Try the following to decrease your paging while the program is running. Increase wsquota and wsextent and wsdefault to high numbers. Increase the maximum ws parameter in sysgen (I don't know the name) Modify the program to lock itself into memory. Increase the size of the free list and modified list so that some of those page faults are not real faults. Increase the initial size of your stack if your program uses a lot of stack. However, You can't get rid of all page faults. When a program is run, it is not loaded into memory. It simply has the page table set up as showing all the pages as being paged out. The pager then loads the program as it is needed. To see how much is real paging, try mon page. If not read or write page values appear, all of your paging is fake. Random Research Triangle Institute ...!mcnc!rti-sel!rcb
info-vax@ucbvax.ARPA (03/06/85)
From: LEICHTER <Leichter@YALE.ARPA>
I just brought up and tuned a 785 with 12Mb of memory. I claim that if
I tweak it correctly, I should be able to do things and not have it
page at all, if I'm the only person logged in [which has so far been
the case]. No funny servers are running; just OPCOM and ERRFMT and me.
Yet I rack up page faults at a respectable rate....
There is no way to eliminate paging completely. An image is demand-paged into
memory as you use it; no amount of available memory can avoid this, since the
data has to get into memory at least once. BUT, the system will still try to
trim your working set if you don't incur any page faults!
Details:
During the run of a single image, once the whole thing is in memory, you can
avoid any further paging by having a large enough working set. Maximum WS
size is determined by two parameters, the WS quota and WS extent. The quota
is the maximum number of pages an image can request explicitly. The extent is
the maximum number of pages the system will grant an image implicitly if it
has a lot of faults and there is a bunch of free memory available. Both of
these parameters can be changed for a process with the DCL SET WORKING_SET
command. In addition, the UAF entry for an account sets absolute maximum
values for these parameters. Finally, the SYSGEN parameter WSMAX sets an
absolute, system-wide limit to the size of any process working set.
BUT, VMS also has a facility for automatic WS size adjustment. Two
parameters, PFRATL and PFRATH, define a range within which VMS will try to
keep a process's page fault rate. If a process's page fault rate is less than
PFRATL, VMS will attempt to take away WSDEC pages. Similarly, it it's above
PFRATH, VMS will try to give it WSINC more pages. These four parameters are
settable using SYSGEN. They are all dynamic parameters, by the way, so you
can do experiments on the fly.
If WSINC is 0, automatic working set adjustment is disabled system-wide. A
process can disable automatic working set adjustment for itself as well; the
DCL SET WORKING_SET command's /[NO]ADJUST qualifier controls this.
Processes can also control the pager in other ways. For example, pages can be
locked in the working set ($LKWSET), and the entire process can be locked in
the balance set ($SETSWM); or pages can be locked into memory ($LCKPAG).
Finally, it's also important to note that there are "soft" and "hard" page
faults in VMS. A soft page fault is one that can be satisfied from a page
that is already in memory, perhaps waiting in some queue or look-aside list.
(For example, the Modified Page List.) It involves no disk I/O. (A "hard"
page fault is a fault that really goes to the disk.)
What I would guess that you are seeing is:
- Automatic working set adjustment enabled, so VMS keeps trimming
your working set down to maintain a "reasonable" number of
faults;
- Since there is plenty of free memory around, just about all your
page faults are "soft".
Try doing a simple SET WORK/NOADJUST; it will probably do the trick. If you
really want to, there are, as you can see, tons of parameters to hack with
beyond that. Be warned, however: It's much, much easier to screw up a VMS
system by trying to "fine-tune" it than it is to actually improve its
performance! See the V4 "Guide to VAX/VMS Performance Management" for more
details. A brief summary of this book is: First, leave things alone.
Second, get more memory. Third, get more of something else (like a bigger
CPU.) Finally, if all else fails, tweak just a bit. (There are obviously
exceptions to this, but they are fairly rare cases of specialized loads.)
-- Jerry
PS: The system itself can page, too. In fact, the recommended settings for
the relevent parameters - like SYSMWCNT, the quota for the system WS - cause a
low but non-zero rate of system page faults. Paging is not an absolute evil -
it's a matter of balancing various demands for a given resource (main memory).
-- J
-------info-vax@ucbvax.ARPA (03/06/85)
From: Mark Johnson <MHJohnson@HI-MULTICS.ARPA> Two things to look at... 1) I you are running your own applications (anything YOU link) then look at the VMS Linker and the options files. The CLUSTER line can be used to change the page-fault-cluster for a section of memory. If you set it big enough, one page fault per cluster ought to bring the whole cluster into memory. This is in both the V3 (p 3-6) and V4 (p LINK-20) linker documentation. 2) The SYSGEN parameter PFCDEFAULT could also be cranked up to make the changes system wide. Lets look at what would happen if you do this. Each page fault would bring in a large number of pages into memory. This increases overall access to the disk & chews up more memory. If you run programs infrequently and have lots of memory to spare, this should be ok. Response time after the initial load should stay good and if the WS parameters are set right the CPU overhead should be near NIL. If you access a lot of programs & are running short of memory, this sort of change would clobber the system since the I/O to the disk would go through the roof. I think the VMS developers assume the VAXen are normally quite loaded so they skew the numbers away from optimal performance on lightly loaded systems and give you the tools to put the parameters where you need them. I can also forsee some tradeoff's depending on what kind of disks you use. The MASSBUS RP07's & other MBA disks are better for fewer large size transfers than RA81's. Where the RA disks come out on top is lots of smaller transfers from many jobs (so seek ordering comes into play). Its a little late to change your disk drives now, but it is something to consider for later improvements. I would also check other parameters that affect your working set. In particular, the SYSGEN parameters WSMAX, SYSMWCNT, WSINC, WSDEC, PFRATL, PFRATH, AWSMIN, AWSTIME, GROWLIM, and BORROWLIM make affects on the whole system. For individual jobs, look at the authorization file for WSDEFAULT, WSEXTENT, and WSQUOTA. Read the documentation carefully and check the job with SHOW SYSTEM or something else to check your job has all the memory you think its getting. --Mark <MHJohnson @ HI-MULTICS.ARPA>
info-vax@ucbvax.ARPA (03/06/85)
From: awalker.rx@XEROX.ARPA hi send me a copy of your status for sysgen and i will compare it against our system..and yes you cannot get rid of paging alan
info-vax@ucbvax.ARPA (03/08/85)
From: ihnp4!stolaf!lacroix@BERKELEY (LaCroix, Les)
The VMS image activator merely maps memory tables and image files, and
then lets the paging facility decide what pages from disk are to be brought
in. That may be what some of your paging is all about, and I don't think
there's anything you can do about that.
Les LaCroix (...{ihnp4,decvax}!stolaf!lacroix)info-vax@ucbvax.ARPA (03/16/85)
From: ulysses!clyde!watmath!utcsri!orton@BERKELEY (Ed Orton) Have you increased WSMAX in sysgen to accomodate the larger working set size? The maximum size of a working set is the maximum allowed for your process OR WSMAX, whichever is LESS. You are still going to have page faults on starting up your process if WSDEFAULT for your process is too small.