So from what I understand, transient free space is either data or
instructions or programs not often used by the system and from  memory
pressure is temporarily stored on disk.  If I have only 3% of the available
10Gbytes of reserved transient space used then and my system is maxed out at
1.5 Gybtes of Ram, I will hardly gain any speed by moving transient space to
a ram disk.

Is this correct?

Another Question is:  Data that is seldom used in memory gets trashed out,
does it go into transient free space first or is it simply written over in
memory?

Jean Huot
Northern Credit Bureaus Inc.
----- Original Message -----
From: "Gavin Scott" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, January 22, 2001 7:55 PM
Subject: Re: [HP3000-L] Any rule of thumb to determine if transient free
space can be a bottleneck?


> Jean writes:
> > I have 3% transient free space used on LDEV 1 and 2 combined i.e.
> > approx : 174 Mbytes.  I'm curious to know if transient free
> > space can be an io  bottleneck.
>
> Here are some thoughts on the subject, which others with more direct
> knowledge will no doubt supplement/correct as needed.
>
> What is called Transient Space on MPE would be called Swap Space on Unix
> (and other operating systems).
>
> When you create an "object" in memory that is not memory resident and
which
> does not already have disk storage associated with it (i.e. it's not
> actually a file on disk as program code or a mapped file would be) then
the
> system will allocate space on disk to hold pages from that object should
> memory pressure become high enough that it wants to "swap out" some or all
> of that object to make room for more important (or more popular) data.
>
> The allocation of transient space is done by essentially building an
> invisible file large enough to hold the maximum size of the memory object,
> but without allocating all the space at once.  As you actually touch pages
> of the object in memory that have not yet been used, the system will make
> sure that the transient space "file" corresponding to that object has been
> expanded at least far enough to hold the new page that you're touching for
> the first time.  The disk space allocation seems to take place in
"extents"
> just as it does for ordinary files.  For "large" objects, the first
> allocation will result in something like 1/30th the maximum possible
amount
> of disk space that the object might need.  So if you run an NM program
with
> a huge ;NMSTACK=100000000, you'll probably find that your transient space
> usage goes up by something like 1/30th of this value to start with.
>
> The key here is that while that space is allocated, it may never actually
be
> written to.  The amount of transient space in use on a system tells you
> something (but not much really) about the total size of all the swappable
> objects in memory (that aren't already files) but nothing about whether
> you're actually doing any I/O to that space (i.e. swapping).
>
> Besides operating system tables not associated with any particular process
> or job/session, most of transient space is used for process stack (and
heap)
> objects and various miscellaneous operating system structures that are
> created on a per process or possibly per-job/session basis.  Transient
space
> usage probably scales fairly linearly with the number of processes and the
> number of users on the system.
>
> As far as whether I/O to transient space is a bottleneck or not, I suspect
> that for most systems it probably is not.  I think most MPE systems
probably
> have enough memory to keep the "transient" objects in memory that are
> important (like stacks for active processes) and that by the time it
becomes
> a bottleneck, performance will be so bad that "speeding up" access to
> transient space won't help much.  You don't want to spend your money
making
> swapping fast, you want to spend your money to make sure that swapping
> doesn't have to happen in the first place.  I.e. if you buy enough memory,
> you'll never be doing any significant I/O to that transient space at all.
A
> dollar used to buy memory is much better spent than one used to buy faster
> access to transient space.
>
> Also memory management in MPE is done at the PAGE (4KB chunk) level, not
at
> the whole-object level as it was in MPE/V, and MPE seems to be pretty good
> at keeping the parts of the objects that you want in memory there.
>
> Transient space is allocated across all disks in the
> MPEXL_SYSTEM_VOLUME_SET, and it's done dynamically unlike some Unix
systems
> where you have to dedicate large (i.e. worst case) amounts of disk storage
> to swapping ahead of time, and changing the allocation can mean
> repartitioning your disk drives.
>
> G.
>