Path: gmdzi!unido!mcsun!uunet!snorkelwacker.mit.edu!usc!wuarchive!bcm!rice!news
From: an...@crysiris.rice.edu (Anand Kolatkar)
Newsgroups: comp.sys.sgi
Subject: Free memory seems low
Message-ID: <1991Jan24.155817.22594@rice.edu>
Date: 24 Jan 91 15:58:17 GMT
Sender: n...@rice.edu (News)
Organization: Rice University
Lines: 18


	I am wondering if the following situation is normal:

	I work on a 4D-20 (3.3.1) with 8M memory.

	When I login when noone else is logged on or running anything, 
	osview shows only 1.2M of memory available (if I am logged in
	from a non console terminal) and 400-500K of memory when I
	login from the console.  This is the free memory showed by osview.

	Is it normal to have only 1/8 of the memory available?

	Any answers would be appreciated.
				
--
//     Anand Kolatkar	 	E-mail: an...@crysiris.rice.edu    //
//     Rice University						   //
//     Dept. of Biochemistry and Cell Biology			   //

Path: gmdzi!unido!fauern!sun1.ruf.uni-freiburg.de!ira.uka.de!
sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!
sgi!shinobu!odin!patton.wpd.sgi.com!jmb
From: j...@patton.wpd.sgi.com (Jim Barton)
Newsgroups: comp.sys.sgi
Subject: Re: Free memory seems low
Message-ID: <1991Jan29.022252.2860@odin.corp.sgi.com>
Date: 29 Jan 91 02:22:52 GMT
References: <1991Jan24.155817.22594@rice.edu>
Sender: n...@odin.corp.sgi.com (Net News)
Reply-To: j...@patton.wpd.sgi.com (Jim Barton)
Organization: Silicon Graphics Inc.
Lines: 32

In article <1991Jan24.155817.22...@rice.edu>, an...@crysiris.rice.edu
(Anand Kolatkar) writes:

> 	I work on a 4D-20 (3.3.1) with 8M memory.
> 
> 	When I login when noone else is logged on or running anything, 
> 	osview shows only 1.2M of memory available (if I am logged in
> 	from a non console terminal) and 400-500K of memory when I
> 	login from the console.  This is the free memory showed by osview.
> 
> 	Is it normal to have only 1/8 of the memory available?
> 
> 	Any answers would be appreciated.

The "Free" line for memory is the amount of memory that currently has no
valid data. In 3.3 and later systems, all of memory is treated as a
cache. All of the memory which is specified as "Userdata" is available
as well. This memory can in general be stolen immediately, since there
is a valid copy of it on backing store.

The only memory unavailable for the user is "Locked" (typically kernel,
but can include memory locked using plock(2) or mpin(2)), "Sysdata"
(process specific data) and "Delwri" (memory on the way to disk). The
gr_osview(1) man page describes these things in gory detail, and the
information applies equally to osview(1).

My guess is that 5-6MB of memory is actually available with Userdata and
Free added together.

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

Path: gmdzi!unido!mcsun!uunet!munnari.oz.au!goanna!minyos.xx.rmit.oz.au!godzilla!mg
From: mg@ (Mike Gigante)
Newsgroups: comp.sys.sgi
Subject: Re: Free memory seems low
Message-ID: <mg.665224839@godzilla>
Date: 30 Jan 91 08:40:39 GMT
References: <1991Jan24.155817.22594@rice.edu> <1991Jan29.022252.2860@odin.corp.sgi.com>
Sender: rxx...@minyos.xx.rmit.oz.au (Greg Farrelly)
Organization: RMIT Computer Centre, Melbourne Australia.
Lines: 99

j...@patton.wpd.sgi.com (Jim Barton) writes:

>In article <1991Jan24.155817.22...@rice.edu>, an...@crysiris.rice.edu
>(Anand Kolatkar) writes:

>> 	I work on a 4D-20 (3.3.1) with 8M memory.
>> 
>> 	When I login when noone else is logged on or running anything, 
>> 	osview shows only 1.2M of memory available (if I am logged in
>> 	from a non console terminal) and 400-500K of memory when I
>> 	login from the console.  This is the free memory showed by osview.
>> 
>> 	Is it normal to have only 1/8 of the memory available?
>> 
>> 	Any answers would be appreciated.

> [ .. details on gr_osview and disk buffers etc]


>My guess is that 5-6MB of memory is actually available with Userdata and
>Free added together.

>-- Jim Barton
>   Silicon Graphics Computer Systems
>   j...@sgi.com

Well, I don't think that is right. Here is a 'ps -el' run on a PI here
in a typical login session. I have 3 wsh's (1 rlogin to server, two local),
a clock, calendar and the X calculator. Not extravagant by any means and
pretty typical around here.

[hedora.cgl.rmit.oz.au, ps -el, 4D25G, 16Mb memory, 200Mb system disk,
all user files NFS mounted from server (4D/220, 2.4Gb disk)]

 F S  UID   PID  PPID  C PRI NI P   SZ:RSS     WCHAN TTY       TIME COMD
39 S    0     0     0  0   0 20 *    0:0    80108c50 ?         0:00 sched
30 S    0     1     0  0  39 20 *   31:18   80109228 ?         0:27 init
39 S    0     2     0  0   0 20 *    0:0    801051e0 ?         0:00 vhand
39 S    0     3     0  0  20 20 *    0:0    80109548 ?         0:09 bdflush
30 S    0  3786     1  0  26 20 *   66:58   80108c20 console   0:01 grcond
30 S    0   100     1  0  26 24 *   35:35   80108c20 ?         0:01 portmap
30 S    0   203     1  0  28 20 *   40:24   80109228 ttyd1     0:00 getty
30 S    0    35     1  0  26 20 *   48:44   80108c20 ?         0:01 syslogd
30 S  903  4037  4036  0  39 20 *   52:28   80109228 ttyq1     0:01 csh
30 S    0    93     1  0  26 20 *   46:24   80108c20 ?         0:42 routed
30 S    9   180     1  0  26 20 *   47:33   801e1cc0 ?         0:00 lpsched
b0 S    0   110     1  0  26 20 *    0:0    80109480 ?         0:00 nfsd
30 S    0   112   110  0  26 20 *    0:0    80109480 ?         0:00 nfsd
30 S    0   113   110  0  26 20 *    0:0    80109480 ?         0:00 nfsd
30 S    0   114   110  0  26 20 *    0:0    80109480 ?         0:00 nfsd
30 S    0   115     1  0  26 20 *    0:0    80126f70 ?         0:00 biod
30 S    0   116     1  0  26 20 *    0:0    80126f70 ?         0:00 biod
30 S    0   117     1  0  26 20 *    0:0    80126f70 ?         0:00 biod
30 S    0   118     1  0  26 20 *    0:0    80126f70 ?         0:01 biod
30 S    0   126     1  0  26 20 *   42:39   80108c20 ?         0:01 inetd
b0 S    0   131     1  0 +30 20 *   45:25            ?         0:00 timeslav
30 S    0   136     1  0  26 20 *  118:83   80109480 ?         0:19 rwhod
30 S  903  4062  4037  0  26 20 *  222:190  80108c20 ttyq1     0:02 xcalc
30 S  903  3803  3797  0  39 20 *   52:28   80109228 console   0:00 csh
30 S    0   185     1  0  26 20 *   65:30   80108c20 ?         0:00 lpd
30 S    0   176     1  0  26 24 *  174:122  8010941c ?         0:01 sendmail
30 S    0   195     1  0  26 20 *   49:28   80b64b58 ?         0:19 cron
30 S  903  3797  3786  0  26 10 *  279:94   80108c20 console   0:11 wsh
30 S  903  4036     1 15  26 10 *  270:86   80108c20 ?         0:03 wsh
30 S    0  3792  3786  3  26 20 *  635:490  80108c20 console   0:30 news_ser
30 S  903  3816     1  0  26 20 *  459:249  80108c20 console   0:02 Xsgi
30 S  903  4046     1  0  26 10 *   50:50   80108c20 ?         0:00 wsh
30 S  903  4057     1  1  26 20 *   33:33   807be85c ttyq2     0:00 clock
b0 S  903  3820  3803  0  28 20 *   29:29   80109638 console   0:01 rlogin
30 S  903  3821  3820  0  26 20 *   30:30   80109480 console   0:01 rlogin
30 S  903  3817  3816  0  26 20 *   97:53   8073901c console   0:00 Xsgi
30 S  903  4047  4046  0  28 20 *   52:28   80109638 ttyq2     0:00 csh
30 R  903  4066  4037 10  64 20 0   36:36            ttyq1     0:00 ps
30 S  903  4055     1  0  26 20 *   97:33   80813bbc ttyq2     0:00 ical

A little calculation shows that the total virtual memory utilized is
2915 pages = 11.66Mb, working set size (real memory used) is 2020 pages
= 8.08Mb

On a 8Mb machine, a larger portion of the total virtual space would be paged 
out.

I can confirm that on an 8Mb PI (this machine used to be 8Mb),
Any compilations would start serious paging in this environment, 
applications did little else besides page.

In any case, Jim Barton's estimate seems *way* off...

(to be fair, NeWS and X are major offenders - maybe Jim wasn't including
those when he should have (at least NeWS))

What I would like to know is why 3 "wsh" windows should take a total
of 601 pages (2.4Mb) of virtual memory? Doesn't it use the shared libraries?
Even xterm uses less than half the space of wsh!!!

Mike Gigante,
ACGC
Royal Melbourne Institute of Technology
m...@godzilla.cgl.rmit.oz.au

Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!caen!sdd.hp.com!
elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!patton.wpd.sgi.com!jmb
From: j...@patton.wpd.sgi.com (Jim Barton)
Newsgroups: comp.sys.sgi
Subject: Re: Free memory seems low
Message-ID: <1991Jan30.160150.6467@odin.corp.sgi.com>
Date: 30 Jan 91 16:01:50 GMT
References: <1991Jan24.155817.22594@rice.edu> 
<1991Jan29.022252.2860@odin.corp.sgi.com> <mg.665224839@godzilla>
Sender: n...@odin.corp.sgi.com (Net News)
Reply-To: j...@patton.wpd.sgi.com (Jim Barton)
Organization: Silicon Graphics Inc.
Lines: 29

Having started life a long time ago as a kernel hacker, memory that
isn't allocated to the kernel in some way is "free", i.e., I (the
kernel) can go get it and use it for something else. So, I automatically
calculated the available space as that the kernel wasn't using for
something or hadn't been locked down.

It's quite correct that the memory is full of data and text for running
programs. Most of the time, alot of that memory isn't in use, since
daemons sleep most of the time, biod and nfsd daemons always execute in
the kernel, and working sets are in general much smaller than the actual
program size (there, I did it again. "in use" means that some program
has executed instructions or touched data on that page in the recent past).

The kernel doesn't bother with these pages unless it needs the memory
for something else. "Mr. VM" Mike Thompson says that one thing he does
to find out how much memory is really "free" is to run a program which
simply touches data larger than physical memory. This causes most other
pages to be paged out and allocated to that program. The program then
exits, and if you look quick before any daemons or window managers or
other things run than that memory will be totally "free".

In general, the kernel doesn't run the paging daemon (called 'vhand' in
a ps listing) unless memory gets tight, and it quits when a certain
minimum number of pages have been made available. This avoids any paging
system overhead unless you really need to page.

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