Return-Path: owner-linux-activists@Niksula.hut.fi
Return-Path: <owner-linux-activists@Niksula.hut.fi>
Received: from joker.cs.hut.fi by hydra.Helsinki.FI (4.1/SMI-4.1/36)
	id AA14432; Sun, 7 Feb 93 21:11:43 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61567-2>; Sun, 7 Feb 1993 21:09:56 +0200
From: "Linux Activists" <linux-activists@Niksula.hut.fi>
To: "Linux-Activists" <linux-activists@Niksula.hut.fi>
Reply-To: "Linux-Activists" <linux-activists@Niksula.hut.fi>
X-Note1: Remember to put 'X-Mn-Key: DOC' to your mail body or header
Subject: Linux-Activists - DOC Channel digest. 93-1-7-12:31
X-Mn-Key: DOC
Sender: owner-linux-activists@Niksula.hut.fi
Message-Id: <93Feb7.210956eet.61567-2@niksula.hut.fi>
Date: Sun, 7 Feb 1993 21:09:53 +0200
Status: RO
X-Status: 


Topics:
	 Re: Linux Glossary
	 Example of memory usage


----------------------------------------------------------------------

From: Piers Cawley <pdcawley@cix.compulink.co.uk>
Subject: Re: Linux Glossary
Date: Sun, 7 Feb 1993 13:51:46 +0200





>  FTP put (remember binary mode) to Linux/ALPHA/incoming,
>  if it is not yet releasable i.e. only for doc-project
>  internal use. Linux/ALPHA/incoming files are moved
>  to Linux/ALPHA/doc-project directory. I try to check
>  out that incoming directory dayly/twice daily ...
>  (nothing since uucp docs ;-).

  Right, I'll stick it up today as glossary.tzp (just 'cos Peter
  MacDonald can't type doesn't mean the rest of us have to repeat the
  mistake.

  It weighs in at around 150 pages, and uses the linuxdoc.sty sheet,
  although it doesn't actually look too good yet. If any LaTeX wizards
  out there know of, or can build a glossary type style sheet, then
  it would be appreciated. There are also lots and lots of overfull
  boxes (I think the record stands at around 45pts), generally they
  occur with the short entries that end with a ref. to a man page.
  Personally I'm tempted to either get rid of a lot of these, or to
  radically extend them to give more detail.

  The package comes as 27 files which all have RCS headers, so you
  can do a ci -k to check them all in.

  If you make any changes, please send cdiffs, and I'll consolidate
  and repost.

-----
Piers
pdcawley@cix.compulink.co.uk




------------------------------

From: Sander van Malssen <sander@kozmix.hacktic.nl>
Subject: Example of memory usage
Date: Sun, 7 Feb 1993 13:52:37 +0200




Hi,

A while ago I played around a little with my system to see where all the
memory went into. I have expanded it a bit into a couple of paragraphs
which I offer to anyone who thinks they can use it in their work. Since
I know little about kernel-internals, I'd also appreciate it if people
would send any corrections or inprovements to me.

Sander


--------------------------------[cut here]--------------------------------


		Example of memory usage: A Case Study
		=====================================

	    Sander van Malssen <sander@kozmix.hacktic.nl>


Here is an example of how memory is allocated on my computer (a
386sx/25 with 5 MB).

>From the boot-up screen:

Memory: 4516k/5376k available (380k kernel, 384k reserved, 96k data)

>From free(1):

             total       used      cache       free     shared
memory:       4516       1288       1076       2152        740


This means that there is a total of 5376k on this machine (actually
5120k, see below), 380k + 384k + 96k = 860k of which is in use as
Kernel memory, leaving 4516k available for programs.  Note that the
number '5376' actually refers to a memory address; this simply means
that the computer's memory has addresses that lie between 0 and 5376k.
Whether all of those addresses between these two numbers actually have
a byte of memory that they point to is a different matter.

In this case there is 5120k installed memory, 256k of which is mapped
from within the area between 768k-1024k towards the end.  This means
that there is 'real' memory behind the addresses 0-640k and
1024k-5376k (adding up to a total of 5120k), video memory somewhere
between 640k-768k depending on your type of monitor, and nothing
between 768k-1024k.  Note that some bioses don't support this memory
reallocation; in that case those 256k stay where they really are and
remain unused.  The reserved kernel memory covers the hole left by
this relocation, and the rest of the area between 640k and 1024k where
the video memory and all the ROMs live.

What I just called 'real' memory is the memory that is available for
the operating system and user programs.  In this particular case the
operating system uses 388k + 96k = 484k, leaving 4516k for your
programs.  This last number is what free(1) reports for 'total
memory'.  Of this memory some will already be used by the time you
have logged in and are able to type 'free': init which is spawned by
the kernel at boot-up, daemons started up from /etc/rc (or
/etc/inittab depending on which init you're running), one getty for
each terminal (virtual or serial) waiting for someone to log in, the
shell for each terminal that someone has logged in to, and whatever
programs you might be running in the background from the shell.  In my
case, I have already spilled almost 1.3 MB of my precious memory
before I get a chance to actually /run/ a program from the command
line.  If you're short of memory, you can perhaps save some by cutting
down on the number of daemons you're running and/or the number of
virtual terminals you're using (see your /etc/inittab for the last
one).

The cache dynamically allocates its memory from the free memory pool.
This means that it can grow in size whenever it needs to, and shrinks
again whenever the memory 'borrowed' from the free memory pool is
needed for your programs.  If you want to know how much free memory
you really have from looking at free(1)'s output, you have to add up
the numbers for 'cache' and 'free' (actually, since the cache has a
certain minimum size that I can't remember right now, you have to
substract a few hundred k to account for that).

The story above adds up to the following picture.  In this particular
case you'd have the kernel and data areas in the first 388k + 96k =
484k, followed by a bit of user memory up to 640k, then the reserved
area from 640k to 1024k, followed finally by the rest of the user
memory.  Note that the user memory is split up by the reserved area,
an inevitable consequence of IBM's original design for the PC.  This
doesn't show up however to the user programs, since the operating
system provides each of these with a slice of memory that pretends to
start at address 0 of its own.  This also keeps programs from
interfering with each other or with the kernel, by the way.  Those are
truly the joys of Real Operating Systems and Protected Mode Processors.


 5376	---------- 
	|	 |
	|	 |
	|	 |
	|  3228	 |	Free & Cache
	|	 |
	|	 |
	|	 |
	---------- 
	|	 |
	|  1288	 |	init, getty, daemons, sh, etc.
	|	 |
 1024	---------- 
	|   384	 |	Reserved
  640	----------
	|   156	 |	init, getty, daemons, sh, etc.
	==========
	|    96	 |	Data
	----------
	|   388	 |	Kernel
    0	---------- 

--------------------------------[cut here]--------------------------------
-- 
Sander van Malssen
sander@kozmix.hacktic.nl



------------------------------

End of DOC Digest
*****************
-------
