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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]