From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
linux-mm@kvack.org, linux-kernel@vger.rutgers.edu,
Stephen Tweedie <sct@redhat.com>
Subject: Re: RFC: design for new VM
Date: Wed, 16 Aug 2000 16:10:03 +0100 [thread overview]
Message-ID: <20000816161003.G19260@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10008031020440.6384-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Thu, Aug 03, 2000 at 11:05:47AM -0700
Hi,
I'm coming to this late -- I've been getting drenched in the Scottish
rain up in Orkney and Skye for the past couple of weeks.
On Thu, Aug 03, 2000 at 11:05:47AM -0700, Linus Torvalds wrote:
> Why don't you just do it with the current scheme (the only thing needed to
> be added to the current scheme being the aging, which we've had before),
> and prove that the _balancing_ works. If you can prove that the balancing
> works but that we spend unnecessary time in scanning the pages, then
> you've proven that the basic VM stuff is right, and then the multiple
> queues becomes a performance optimization.
>
> Yet you seem to sell the "multiple queues" idea as some fundamental
> change. I don't see that. Please explain what makes your ideas so
> radically different?
> As far as I can tell, the above is _exactly_ equivalent to having one
> single list, and multiple "scan-points" on that list.
I've been talking with Rik about some of the other requirements that
filesystems have of the VM. What came out of it was a strong
impression that the VM is currently confusing too many different
tasks.
We have the following tasks:
* Aging of pages (maintaining the information about which pages are
good to reclaim)
* Reclaiming of pages (doesn't necessarily have to be done until
the free list gets low, even if we are still doing aging)
* Write-back of dirty pages when under memory pressure (including
swap write)
* Write-behind of dirty buffers on timeout
* Flow-control in the VM --- preventing aggressive processes from
consuming all free pages to the detriment of the rest of the
system, or from filling all of memory with dirty, non-reclaimable
pages
Rik's design specified that page aging --- the location of pages
suitable for freeing --- was to be done on a physical basis, using
something similar to 2.0's page walk (or FreeBSD's physical clock).
That scan doesn't have to walk lists: its main interaction with the
lists would be to populate the list of pages suitable for reclaim.
Once page aging is cleaned up in that way, we don't have to worry
overly about the scan order for pages on the page lists. It's much
like the buffer cache --- we can use the buffer cache locked and dirty
lists to simplify the tracking of dirty data in the buffer cache
without having to worry about how those lists interact with the buffer
reclaim scan, since the reclaim scan is done using a completely
different scanning mechanism (the page list).
The presence of multiple queues isn't the Radically Different feature
of Rik's outline. The fact that aging is independent of those queues
is.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-08-16 15:10 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-02 22:08 Rik van Riel
2000-08-03 7:19 ` Chris Wedgwood
2000-08-03 16:01 ` Rik van Riel
2000-08-04 15:41 ` Matthew Dillon
2000-08-04 17:49 ` Linus Torvalds
2000-08-04 23:51 ` Matthew Dillon
2000-08-05 0:03 ` Linus Torvalds
2000-08-05 1:52 ` Matthew Dillon
2000-08-05 1:09 ` Matthew Wilcox
2000-08-05 2:05 ` Linus Torvalds
2000-08-05 2:17 ` Alexander Viro
2000-08-07 17:55 ` Matthew Dillon
2000-08-05 22:48 ` Theodore Y. Ts'o
2000-08-03 18:27 ` lamont
2000-08-03 18:34 ` Linus Torvalds
2000-08-03 19:11 ` Chris Wedgwood
2000-08-03 21:04 ` Benjamin C.R. LaHaise
2000-08-03 19:32 ` Rik van Riel
2000-08-03 18:05 ` Linus Torvalds
2000-08-03 18:50 ` Rik van Riel
2000-08-03 20:22 ` Linus Torvalds
2000-08-03 22:05 ` Rik van Riel
2000-08-03 22:19 ` Linus Torvalds
2000-08-03 19:00 ` Richard B. Johnson
2000-08-03 19:29 ` Rik van Riel
2000-08-03 20:23 ` Linus Torvalds
2000-08-03 19:37 ` Ingo Oeser
2000-08-03 20:40 ` Linus Torvalds
2000-08-03 21:56 ` Ingo Oeser
2000-08-03 22:12 ` Linus Torvalds
2000-08-04 2:33 ` David Gould
2000-08-16 15:10 ` Stephen C. Tweedie [this message]
2000-08-03 19:26 ` Roger Larsson
2000-08-03 21:50 ` Rik van Riel
2000-08-03 22:28 ` Roger Larsson
2000-08-04 13:52 Mark_H_Johnson
[not found] <8725692F.0079E22B.00@d53mta03h.boulder.ibm.com>
2000-08-07 17:40 ` Gerrit.Huizenga
2000-08-07 18:37 ` Matthew Wilcox
2000-08-07 20:55 ` Chuck Lever
2000-08-07 21:59 ` Rik van Riel
2000-08-08 3:26 ` David Gould
2000-08-08 5:54 ` Kanoj Sarcar
2000-08-08 7:15 ` David Gould
[not found] <87256934.0072FA16.00@d53mta04h.boulder.ibm.com>
2000-08-08 0:36 ` Gerrit.Huizenga
[not found] <87256934.0078DADB.00@d53mta03h.boulder.ibm.com>
2000-08-08 0:48 ` Gerrit.Huizenga
2000-08-08 15:21 ` Rik van Riel
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=20000816161003.G19260@redhat.com \
--to=sct@redhat.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--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