linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	jfm2@club-internet.fr, linux-mm@kvack.org
Subject: Re: Two naive questions and a suggestion
Date: Wed, 25 Nov 1998 14:46:38 GMT	[thread overview]
Message-ID: <199811251446.OAA01094@dax.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.3.96.981125140245.8544A-100000@mirkwood.dummy.home>

Hi,

On Wed, 25 Nov 1998 14:08:47 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> On Wed, 25 Nov 1998, Stephen C. Tweedie wrote:
>> Rick, get real: when will you work out how the VM works?  We can
>> safely implement RSS limits *today*, and have been able to since
>> 2.1.89.  <grin> 

> If we tried to implement RSS limits now, it would mean that
> the large task(s) we limited would be continuously thrashing
> and keep the I/O subsystem busy -- this impacts the rest of
> the system a lot.

WRONG.  We can very very easily unlink pages from a process's pte (hence
reducing the process's RSS) without removing that page from memory.
It's trivial.  We do it all the time.  We can do it both for
memory-mapped files and for anonymous pages.  In the latest 2.1.130
prepatch, this is in fact the *preferred* way of swapping.  This
mechanism is fundamental to the way we maintain page sharing of swapped
COW pages.

The only thing we cannot do is unlink dirty pages (for swap, that means
pages which have been modified since we last paged the swap back into
memory).  We have to write them back before we unlink.  That does not
mean that we have to throw the data away: as long as the copy on disk is
uptodate, we can have as much of a process's address space as we want in
the page cache or swap cache without it being mapped in the process'
address space and without it counting as task RSS.

Today, such an RSS limit would NOT thrash the IO: it would just cause
minor page faults as we relink the cached page back into the page
tables.  All of that functionality exists today.

Rik, you should probably try to work out how try_to_swap_out() actually
works one of these days.  You'll find it does a lot of neat stuff you
seem to be unaware of!  We are really a lot closer to having a proper
unified page handling mechanism than you think.  The handling of dirty
pages is pretty much the only missing part of the mechanism right now.
Even that is not necessarily a bad thing: there are good performance
reasons why we might want the swap cache to contain only clean pages:
for example, it makes it easier to guarantee that those pages can be
reclaimed for another use at short notice.

--Stephen
--
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-25 14:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-11-19  0:20 jfm2
1998-11-19 20:05 ` Rik van Riel
1998-11-20  1:25   ` jfm2
1998-11-20 15:31     ` Eric W. Biederman
1998-11-23 18:08 ` Stephen C. Tweedie
1998-11-23 20:45   ` jfm2
1998-11-23 21:59   ` jfm2
1998-11-24  1:21     ` Vladimir Dergachev
1998-11-24 11:17     ` Stephen C. Tweedie
1998-11-24 21:44       ` jfm2
1998-11-25  6:41         ` Rik van Riel
1998-11-25 12:27           ` Stephen C. Tweedie
1998-11-25 13:08             ` Rik van Riel
1998-11-25 14:46               ` Stephen C. Tweedie [this message]
1998-11-25 16:47                 ` Rik van Riel
1998-11-25 21:02                   ` Stephen C. Tweedie
1998-11-25 21:21                     ` Rik van Riel
1998-11-25 22:29                       ` Stephen C. Tweedie
1998-11-26  7:30                         ` Rik van Riel
1998-11-26 12:48                           ` Stephen C. Tweedie
1998-11-25 20:01           ` jfm2
1998-11-26  7:16             ` Rik van Riel
1998-11-26 19:59               ` jfm2
1998-11-27 17:45                 ` Stephen C. Tweedie
1998-11-27 21:14                   ` jfm2
1998-11-25 14:48         ` Eric W. Biederman
1998-11-25 20:29           ` jfm2
1998-11-25 16:31         ` ralf
1998-11-26 12:18           ` 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=199811251446.OAA01094@dax.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=jfm2@club-internet.fr \
    --cc=linux-mm@kvack.org \
    /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