linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
To: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
Cc: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>,
	"Benjamin C.R. LaHaise" <blah@kvack.org>,
	linux-mm@kvack.org, torvalds@transmeta.com
Subject: Re: reverse pte lookups and anonymous private mappings; avl trees?
Date: Thu, 5 Mar 1998 22:25:50 GMT	[thread overview]
Message-ID: <199803052225.WAA01125@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.91.980305001855.1439B-100000@mirkwood.dummy.home>

Hi,

On Thu, 5 Mar 1998 00:20:39 +0100 (MET), Rik van Riel
<H.H.vanRiel@fys.ruu.nl> said:

> On Wed, 4 Mar 1998, Stephen C. Tweedie wrote: 

>> 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.)

> We just might want to do that. If we can _guarantee_ a certain
> number of free+(inactive&clean) pages, we can keep the number of
> free pages lower, and we can keep more pages longer in memory,
> giving more speed to the overall system.

I know --- that's precisely the point I was trying to make!  The
"inactive plus clean" pages are exactly the pages we need to keep on a
queue for rapid reclamation, and these pages are guaranteed not to be
mapped.  So, we can overload the queue links with the vma,vm_offset
values (which are only needed for mapped pages, which cannot be so
rapidly reclaimed).

We only have to keep the two structures separate if we ever need to
locate lists of mapped pages, and I was only planning to use unmapped
pages for the fast-reclaim lists (I don't like the idea of twiddling
process page tables from inside interrupts!).

Cheers,
 Stephen

      parent reply	other threads:[~1998-03-05 22:25 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
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 [this message]

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=199803052225.WAA01125@dax.dcs.ed.ac.uk \
    --to=sct@dcs.ed.ac.uk \
    --cc=H.H.vanRiel@fys.ruu.nl \
    --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