RE: Swapfiles
Ah
Ok, so the question becomes do I write the contents of the memory I am
replacing back to disk? For a application I do not, but for data I do (Or
is it even more intelligent and affect only data that has changed?)
One question still remains though (and I am sure many more do as well), what
actually is the swap space considered on the disk? Is the kernel smart
enough to realize that the data pulled in for an executable does not need to
use this space but can be pulled in from the original disk space? Or to
keep the design simple just treat all memory and swap space the same?
Brian
-----Original Message-----
From: Karl E. Jorgensen [mailto:karl@jorgensen.com]
Sent: Thursday, April 18, 2002 6:17 PM
To: debian-user@lists.debian.org
Subject: Re: Swapfiles
On Thu, Apr 18, 2002 at 08:44:16AM -0400, Smith, Brian N. wrote:
> >John Hasler wrote
> >I wrote:
> >> Executables, being read-only, are mapped directly from disk and never
> >> use any swap at all. Only data gets mapped to swap.
>
> >Karsten writes:
> >> Is this a GNU/Linux thing or a more general Unix/POSIX thing?
>
> >Neither. It's a virtual-memory thing. It's the obvious thing to do as
> >soon as you have vm.
>
> >> Recent development or long-time feature.
>
> >VMS had it from day one, I believe, and Berkeley introduced it into Unix
> >when they ported it to the VAX.
>
> I am a little puzzled by the comment "executables do not use swap" and I
> have to admit computer design is not my forte. However let me dive in :-)
Neither am I. Diving in too..
> I was under the impression the swap process did not care what the memory
> was doing, in fact the user process or data did not know it was in ram or
on
> disk, but ran in the virtual memory. If there was a request from part of
> the program running in this virtual memory (hence obviously in ram space
> talking to the processor) and the instruction pointed to an area in
virtual
> memory that was not in ram space the MMU would generate an exception to
> kernal space and the swap would occur. The trick is to guess what parts
of
> the virtual memory should be kept in ram space. (Hence all the design in
the
> kernal world) As well there are some means to request that parts of your
> program remain in RAM space (this used to be a function of the sticky bit
I
> think) but I am not a programmer so I really cannot comment too much on
> this.
It looks like you're both right:
executables *do* swap - there is no need for the loader to load in a
complete executeable before starting to execute it. When new bits of the
executable are needed, they will be paged in (or is it swapped? I
managed to confuse myself again...)
But when the memory manager decides to re-use a bit of memory currently
holding bits of program, then there's *no need* to write it to the swap
partition(s). It can't be dirty, and it can be re-read as required from
the executable file.
So: executables do get swapped, but they don't use swap *space*.
On some unix's (e.g. HP if memory serves - it's been swapped out a long
time), a side-effect of this is not being able to remove executable
files that are currently running - you get "text file busy". The fact
that currently running executables can be removed under Linux, I believe
is due to the cooperation of the file system, which just "hides" removed
files until all references to them are gone. But I may well be wrong on
this, see sig.
--
______________________________________________________________
/\ \
\_| *DISCLAIMER* I do not know exactly what I'm talking about. |
| Large grains of salt recommended to aid in digestion. |
| _________________________________________________________|_
\_/___________________________________________________________/
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: