linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Rik van Riel <H.H.vanRiel@phys.uu.nl>,
	"Dr. Werner Fink" <werner@suse.de>,
	Kernel Mailing List <linux-kernel@vger.rutgers.edu>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: Linux-2.1.129..
Date: 23 Nov 1998 13:16:26 -0600	[thread overview]
Message-ID: <m1r9uudxth.fsf@flinx.ccr.net> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of "Mon, 23 Nov 1998 17:13:34 GMT"

>>>>> "ST" == Stephen C Tweedie <sct@redhat.com> writes:

ST> That would be true if we didn't do the free_page_and_swap_cache trick.
ST> However, doing that would require two passes: once by the swapper, and
ST> once by shrink_mmap(): before actually freeing a page.  This actually
ST> sounds like a *very* good idea to explore, since it means that vmscan.c
ST> will be concerned exclusively with returning mapped and anonymous pages
ST> to the page cache.  As a result, all of the actual freeing of pages will
ST> be done in shrink_mmap(), which is the closest we can get to a true
ST> self-balancing system for freeing memory.

There are a few other reasons this would be useful as well.
1) It resembles a 2 handed clock algorithm.  So there would
  be some real page aging functionality.  And we could reclaim pages
  that we are currently writing to disk.

2) We could remove the swap lock map.

I have wanted to suggest this for a while but I haven't had the time
to carry it through. :(

ST> I'm going to check this out: I'll post preliminary benchmarks and a
ST> patch for other people to test tomorrow.  Getting the balancing right
ST> will then just be a matter of making sure that try_to_swap_out gets
ST> called often enough under normal running conditions.  I'm open to
ST> suggestions about that: we've never tried that sort of behaviour in the
ST> vm to my knowledge.

We might want to look at the balance between the buffer cache writing and
shrink_mmap.  Because that is how those two systems interact already.

Eric


--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-11-23 18:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.3.95.981119002335.838A-100000@penguin.transmeta.com>
1998-11-19 21:34 ` Linux-2.1.129 Dr. Werner Fink
1998-11-19 21:58   ` Linux-2.1.129 Rik van Riel
1998-11-20 12:09     ` Linux-2.1.129 Dr. Werner Fink
1998-11-19 22:33   ` Linux-2.1.129 Linus Torvalds
1998-11-23 17:13     ` Linux-2.1.129 Stephen C. Tweedie
1998-11-23 19:16       ` Eric W. Biederman [this message]
1998-11-23 20:02         ` Linux-2.1.129 Linus Torvalds
1998-11-23 21:25           ` Linux-2.1.129 Rik van Riel
1998-11-23 22:19           ` Linux-2.1.129 Dr. Werner Fink
1998-11-24  3:37           ` Linux-2.1.129 Eric W. Biederman
1998-11-24 15:25           ` Linux-2.1.129 Stephen C. Tweedie
1998-11-24 17:33             ` Linux-2.1.129 Linus Torvalds
1998-11-24 19:59               ` Linux-2.1.129 Rik van Riel
1998-11-24 20:45                 ` Linux-2.1.129 Linus Torvalds
1998-11-25 14:19               ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 21:07                 ` Linux-2.1.129 Eric W. Biederman
1998-11-26 12:57                   ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 20:33             ` Linux-2.1.129 Zlatko Calusic
1998-11-23 19:46       ` Linux-2.1.129 Eric W. Biederman
1998-11-23 21:18         ` Linux-2.1.129 Rik van Riel
1998-11-24  6:28           ` Linux-2.1.129 Eric W. Biederman
1998-11-24  7:56             ` Linux-2.1.129 Rik van Riel
1998-11-24 15:48             ` Linux-2.1.129 Stephen C. Tweedie
1998-11-24 15:38         ` Linux-2.1.129 Stephen C. Tweedie
1998-11-23 20:12       ` Linux-2.1.129 Rik van Riel
1998-11-23 20:53       ` Running 2.1.129 at extrem load [patch] (Was: Linux-2.1.129..) Dr. Werner Fink
1998-11-23 21:59         ` Rik van Riel
1998-11-23 22:35           ` Dr. Werner Fink
1998-11-24 12:38             ` Dr. Werner Fink

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=m1r9uudxth.fsf@flinx.ccr.net \
    --to=ebiederm+eric@ccr.net \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.com \
    --cc=torvalds@transmeta.com \
    --cc=werner@suse.de \
    /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