Jean,

As far as I remember, it goes to transient space until the program asociated
with it has ended. At the program end, all page asociated with the program
are cleared in memomory and transient space.


Regards,


Jan Gerrit

N.B. Sorry, for my poor english. You are allowed to correct the errors.


"LES BUREAUX DE CRÉDIT DU NORD INC" <[log in to unmask]> schreef in bericht
news:94kcfa01f2n@enews4.newsguy.com...
> 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.
> >
>