NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/vmsnet/internal/1191

Internet Message Format | 1992-08-25 | 6.4 KB

Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!infopiz!cmkrnl!jeh
Newsgroups: vmsnet.internals
Subject: re: VMS Tuning
Message-ID: <[e-mail]>
From: [e-mail]
Date: 25 Aug 92 13:15:14 PDT
References: <22200471_00057EE8.0095F9692000E6A0$[e-mail]>
Organization: Kernel Mode Consulting, San Diego, CA
Lines: 111

> Graham Evans writes
>
>> When I get involved in tuning VMS, one of the pieces of education I always do
>> is to tell the system manager or whoever that pages of memory on the free list
>> are not wasted or unused, but are performing a very useful function. I explain
>> that they contain valid information, and can be made available to the relevant
>> process at the modest cost of a soft fault. As a system wide cache, the pages
>> are available to all processes and hence are flexibly available as different
>> processes make their demands, which I see as preferable to an increase in
>> working sets which will tie pages to specific processes.
>>
>> Now from time to time, too often for my liking, I see statements like the
>> following in articles on VMS tuning:
>>
>> "... there are often tens of thousands of pages of memory left on the free
>  page
>> list with no way for the system or processes to get to it. The goal in tuning
>> memory is to free up this unused memory and make it available for the system
>> and processes which can make good use of it"
>>
>> If I am completely deluded in my view, will somebody please tell me!
>

In article <22200471_00057EE8.0095F9692000E6A0$[e-mail]>,
 [e-mail] writes:

> Graham, IMHO you are 100% right. No. make that 200% right. or maybe 1000%.

but then goes on to say

> My experience so far has been that if your system is short of memory [...]

note the qualification:  IF the system is short of memory.

Let's define terms:  "Short of memory" means you don't have enough memory
to give all processes a big enough WSQUOTA to let them all see the desired
performance at the same time.

In this situation, yes, the best strategy is to keep the WSQUOTAs small
(enough for "adequate" performance), let the WSEXTENTs be large (so that during
times when only a few people are on the system, they can each have bigger
working sets), and allow the FPL and MPL to act as a system-wide cache.

Another poster was absolutely correct in stating that the FPL needs to be big
enough (say, a few thousand pages) to allow for rapid allocation of large
numbers of pages at process- and image-startup time.

Let's take the opposite scenario:  A memory-rich production system which
typically runs a few large batch jobs with some light interactive query users.
Both the batch jobs and the interactive users tend to get into one image and
stay there for hours at a time.  Now, if there's enough memory to give them all
WSQUOTAs large enough to reduce even soft faulting to a bare minimum, while
maintaining an adequate reserve for image startup, *why not*????  Why force
them to go to the FPL if they don't need to?

How can you determine if this is your situation?  Simple.  MONITOR PAGE. If you
don't see any hard page faults (except those associated with image
activation)... in other words, if all of the pages released by processes are
still on the MPL or FPL when the processes need them again... there is no point
in forcing those pages to be pushed out to the page caches only to be faulted
back in again.

Think about it this way:  the benefit of using the FPL and MPL as page caches
applies only when you're short on memory.  You keep the WSQUOTAs small enough
so that everybody is forced to put some of their pages out on the FPL and MPL.
Then the pages that are referenced often get faulted back in from the lists
before they're reassigned to someone else, while those that aren't referenced
again soon after being released get released to other processes.  But if you
have enough pages on the lists so that nearly all faults can be resolved to
them... plus enough to allow for image startup... you're keeping too many pages
there!

In other words, it pays to force the processes to use these lists as a cache
only if you don't have enough memory to give to all process working sets in the
first place.  If you have a memory-rich system, you should be following
completely different guidelines.

> If only, IF ONLY, people would understand the difference between soft
> and hard page faults! Soft ones take a fraction of a millisecond of CPU
> time (even on a uv-II), hard ones take many milliseconds and a disk IO.

However, an instruction that generates a soft fault will nevertheless take, oh,
perhaps thirty times as long to execute as one that generates no faults. (I
haven't measured this; I'm guesstimating based on the amount of code that's
involved in working set replacement.)  Consider that a simple two-operand
ADDLong instruction could generate *six* soft faults (two for the instruction
if it happens to straddle a page boundary, two each for the operands if they're
in memory and similarly straddle page boundaries).  If you have the memory
available to reduce soft faults for all processes, while still maintaining an
adequate FPL to support image startup, there is no reason to not allow the
processes to keep those pages in their working sets.

The joker in all of this is that the proper tuning strategy depends on the job
mix, and the job mix changes from moment to moment.  What may be a memory-rich
system at one moment can quickly become a memory-starved system. This is why
using small WSQUOTAs and large WSEXTENTs is a good general strategy:  It allows
the system to let processes have large working sets if the memory is available,
but also allows the working sets to be cut back to the smaller WSQUOTA if more
processes show up.  However, getting BORROWLIM and GROWLIM set to the right
values so that this works properly is non-trivial.  If you have a memory-rich
system it is easier to simply set the WSQUOTAs high and be done with it.

So who's wrong and who's right?  It depends on your situation.  But almost any
advice that gives absolute rules to follow, without regard for your particular
system configuration and load, is best taken with a large grain of salt.

    --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  [e-mail], [e-mail], or [e-mail]
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh