[Gllug] Pages marked as present but not mapped
Christian Smith
csmith at thewrongchristian.org.uk
Wed Aug 31 22:32:34 UTC 2011
On Wed, Aug 31, 2011 at 05:29:32PM +0100, Adrian McMenamin wrote:
> On Wed, August 31, 2011 12:48 am, Nix wrote:
> > On 30 Aug 2011, Christian Smith said:
> >
> >> What I suspect is happening is that you're reading entries for pages
> >> that
> >> are not present (else the present bit would be 1) but are not swapped.
> >
> > Agreed. Some of this may be text pages which haven't been paged in: some
> > may be due to malloc() overcommitment.
> >
> These pages *are* marked as present, at least in the /proc file system.
>
> What they do not have is any page table entry (or swap reference).
>
> Would I be correct in saying/thinking, they are/could be, areas of the
> process virtual memory that have been reserved for, say, more pages of the
> backing file to be read in, but that the file itself has not been read in
> - hence although the space is reserved, there is nothing in it and when at
> attempt is made to reference those addresses, the appropriate page the
> address_space will be read in from backing store and a page table entry
> fixed up.
>
Precisely. That is the whole essence of demand paging. In the case of mmap
file, the data comes from file. In the case of virgin anonymouse memory,
a zero filled page is used (no IO). In the case of already swapped out
pages, the swap address is stored in the PTE as you've seen. The PTE neither
swapped nor present are the virgin untouched pages, which will be zero filled
on demand.
As noted also by Nix, private mmap'ing a file will result in writes to the
pages being written to swap, so it is possible for mmap pages to be associated
with swap. This is for usually for initialized data from an executable or
shared library.
Christian
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list