Why would some process swap in place of reclaiming free(cached) memory

[Soham Chakraborty]

On Thu, Feb 21, 2013 at 10:45 AM, Mandeep Sandhu <
mandeepsandhu.chd at gmail.com> wrote:

> > I know the pages are kept on disk initially and then swapped in as
> needed/referenced.  Thus if there are code pages where none of the code in
> the page has been executed since starting the app, then that page will
> remain on disk until the application logic eventually invokes it.  At that
> point it will be demand loaded from disk.
> >
> > During that early stage, do the never used pages show as swapped out?
>  If so, why would anyone want all those never used pages to be brought into
> ram just to sit there unused?
>
> Are you saying that pages of code segment (of an executable) which
> have not been accessed yet, are copied onto the swap space from their
> location on the disk when the program is exec'ed? Or do they remain on
> disk (in their original location) and loaded into memory only when
> accessed (and _then_ possibly swapped out)? If they remain on disk,
> then that wouldn't show up in swap space, right?
>

If the code segment of an executable which hasn't been accessed, they will
remain on disk because they have fixed filesystem backing. Only when they
are referenced, they will go to cache and then when inactive and/or while
reclaiming, they will end up in disk again. But, afaik, anything which has
a filesystem backing, a fixed storage backing, doesn't go to swap. This
part is pretty clear to me. Only anon pages go to swap and something which
is on disk, is not anon in first place.

Soham

>
> -mandeep
>
> >
> > The end result is that that swap'ed pages represent pages available to
> be swapped in, but not the number of pages that were actually swapped out
> at some point in time.
> >
> > Greg
> > --
> > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130221/7be53f43/attachment.html