From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
To: "Benjamin C.R. LaHaise" <blah@kvack.org>
Cc: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>,
linux-mm@kvack.org, torvalds@transmeta.com
Subject: Re: reverse pte lookups and anonymous private mappings; avl trees?
Date: Wed, 4 Mar 1998 21:26:18 GMT [thread overview]
Message-ID: <199803042126.VAA01736@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.95.980302235716.8007A-100000@as200.spellcast.com>
Hi,
Another observation on the subject of new page lists.
You suggested adding:
> + /* used for private mappings -> inode == NULL or &swapper_inode */
> + struct vm_area_struct *vma;
> + unsigned long vma_offset;
> +
> + /* page on one of the circular page_queues */
> + struct page *pgq_next;
> + struct page *pgq_prev;
to the struct page. However, note that the vma and vma_offset fields
are irrelevant to pages which are not mapped (the fields can be
initialised on first map, and a page which is purely in the page or swap
cache is not attached to any particular vma and so doesn't need these
lookups). Detecting such unmapped pages reliably may require separate
unmapped and mapped page counts.
Given this, can we not over load the two new fields and reduce the
expansion of the struct page? The answer is yes, if and only if we
restrict the new page queues to unmapped pages. For my own code, the
only queue which is really necessary is the list of pages ready to be
reclaimed at interrupt time, and those pages will never be mapped. The
other queues you mention:
> +#define PgQ_Locked 0 /* page is unswappable - mlock()'d */
> +#define PgQ_Active 1 /* page is mapped and active -> young */
> +#define PgQ_Inactive 2 /* page is mapped, but hasn't been referenced recently -> old */
> +#define PgQ_Swappable 3 /* page has no mappings, is dirty */
> +#define PgQ_Swapping 4 /* page is being swapped */
> +#define PgQ_Dumpable 5 /* page has no mappings, is not dirty, but is still in the page cache */
don't seem to give us all that much extra, since we probably never want
to go out and explicitly search for all pages on such lists. (That's
assuming that the page aging and swapping scanner is working by walking
pages in physical address order, not by traversing any other lists.)
Other than that, I like this idea more and more. Overloading these two
sets of fields gives us huge extra functionality over the 2.0 vm, and at
the cost of only one extra longword per page.
Cheers,
Stephen.
next prev parent reply other threads:[~1998-03-04 21:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-03-02 19:04 Benjamin C.R. LaHaise
1998-03-02 23:03 ` Stephen C. Tweedie
1998-03-02 23:37 ` Rik van Riel
1998-03-03 6:29 ` Benjamin C.R. LaHaise
1998-03-03 23:49 ` Stephen C. Tweedie
1998-03-04 21:26 ` Stephen C. Tweedie [this message]
1998-03-04 23:20 ` Rik van Riel
1998-03-05 4:21 ` Benjamin C.R. LaHaise
1998-03-05 22:25 ` Stephen C. Tweedie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199803042126.VAA01736@dax.dcs.ed.ac.uk \
--to=sct@dcs.ed.ac.uk \
--cc=blah@kvack.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox