Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!mips!decwrl!sgi!shinobu!odin!patton.wpd.sgi.com!jmb
From: jmb@patton.wpd.sgi.com (Doctor Software)
Newsgroups: comp.sys.sgi
Subject: Re: Swap questions
Message-ID: <1990Nov16.155730.2670@odin.corp.sgi.com>
Date: 16 Nov 90 15:57:30 GMT
References: <9011150232.AA00704@koko.pdi.com>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: jmb@patton.wpd.sgi.com (Doctor Software)
Organization: Silicon Graphics Inc.
Lines: 75

In article <9011150232.AA00704@koko.pdi.com>, shoshana@koko.UUCP
(Shoshana Abrass) writes:
> 
>   1. Are the image files ever paged out to the swap area? it seems not.
> 	 It seems like the executable code is the only thing getting paged
> 	 to virtual memory.

This is mostly correct. Only pieces of executable programs get swapped
out, whether they are text or data. It would make little sense to swap a
data file - it's already on the disk anyway!

Files are managed through the system "buffer cache", which is an area of
memory used to cache file pages. In IRIX 3.3 and later, the system
dynamically sizes the buffer cache, and will attempt to keep a balance
between executable code and file data in memory to minimize disk traffic
and maximize performance.

> 
>   2. Are the image files 'swapin'ed (according to osview) when they're 
> 	 first read into memory? What's the difference between the "Virtual
> 	 Memory" and "Swap" in osview?

Image file traffic can be examined in the buffer traffic section of
osview, or the "bdev" bar of gr_osview. Also, the real memory section of
osview or the "rmem" and "rmemc" bars of gr_osview show memory usage,
and what is assigned to the buffer cache versus executable code, etc.
The man page for gr_osview describes what all this stuff means in quite
a bit of detail.

In essence, your file is only read into memory as you access it, not all
at once, so to see the traffic effect look at the block device (buffer
cache) information. Virtual memory is paging activity on program text
and data. Paging activity does not necessarily imply disk activity! Page
faults occur for copy-on-write, modifications, zero-on-fill, double TLB
faults, etc. Swap only occurs when, as the "last resort", the system
must push some pages out to disk to make room for other pages. A swapin
only occurs as a "last resort" if a user accesses a page that only
resides on the disk. Going to the disk is expensive - the system avoids
it whenever possible. Again, the man page for gr_osview has a lot more
information on all this stuff.

>   In a kernel class I took, the instructor claimed that whenever a process
>   was read into memory, swap space was reserved/allocated for it, before 
>   it ever got paged out. Is this true under Irix? (is it ever true, for 
>   that matter). If this is true, it implies that one must have at least
>   as much swap as real memory... even though "swap -l" claims that no
>   swap is being used. Also, if it is true, is it only true for the 
>   executable code, and not the data?

Swap space is allocated (it's cheap - just a counter) whenever a new
page of program memory is created. This means that when a program is
started, the text, initial stack and data segments have backing store
allocated in swap. This avoids deadlock of the system. Sar, osview and
gr_osview only report the number of swap pages that actually have an
active copy of a memory page on them - this is different than just
making sure that pages will be available in case swapping is necessary.

To imagine the deadlock, consider what would happen if I started a
program without making sure that swap space was available. I could
already have filled up my swap space with other program data. Then, the
new program allocates a new page of data, and I run out of memory. I
need to swap something to get memory for the new page, but swap space is
full so I can't swap, so ... deadlock.

> 
>   What's the real scoop here? Any help much appreciated.

I think all your questions have been answered!

>   -shoshana
>   pdi!shoshana@sgi.com

-- Jim Barton
   Silicon Graphics Computer Systems
   jmb@sgi.com