linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
	"Eric W. Biederman" <ebiederm+eric@ccr.net>,
	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: Wed, 25 Nov 1998 14:19:28 GMT	[thread overview]
Message-ID: <199811251419.OAA00990@dax.scot.redhat.com> (raw)
In-Reply-To: <Pine.LNX.3.95.981124092641.10767A-100000@penguin.transmeta.com>

Hi,

On Tue, 24 Nov 1998 09:33:11 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> said:

> On Tue, 24 Nov 1998, Stephen C. Tweedie wrote:
>> 
>> Indeed.  However, I think it misses the real advantage, which is that
>> the mechanism would be inherently self-tuning (much more so than the
>> existing code).

> Yes, that's one of the reasons I like it.

> The other reason I like it is that right now it is extremely hard to share
> swapped out pages unless you share them due to a fork(). The problem is
> that the swap cache supports the notion of sharing, but out swap-out
> routines do not - they swap things out on a per-virtual-page basis, and
> that results in various nasty things - we page out the same page to
> multiple places, and lose the sharing. 

No, I fixed that in 2.1.89.  Shared anonymous pages _must_ be COW and
therefore readonly (this is why moving to MAP_SHARED anonymous regions
is so hard).  So, the first process which tries to swap such a shared
page will write it to disk and set up a swap cache entry.  Because the
page is necessarily readonly, we can safely assume it is OK to write it
at this point and not at the point of the last unmapping.

Subsequent processes which pageout the same page will find it in the
swap cache already and will just free the page.  I've tested this with a
program which sets up large anonymous region, forks, and then thrashes
the memory.  On prior kernels we lose the sharing, but on 2.1.89 and
later, that sharing is maintained perfectly even after fork and we never
grow the amount of swap which is used.

> The VM policy changes weren't stability issues, they were only "timing". 
> As such, if they broke something, it was really broken before too. 

Absolutely.

> And I agree that the mechanism is already there, however as it stands we
> really populate the swap cache at page-in rather than page-out, and
> changing that is fairly fundamental. It would be good, no question about
> it, but it's still fairly fundamental. 

We still have to populate the swap cache at page-in time.  The initial
reason for the early swap cache implementation was to prevent us from
having to re-write to disk pages which are still clean in memory.  For
that to work we need to cache the page-in.

However, for pages which become dirty in memory, we _do_ populate the
swap cache only at page-out time.  That's why the sharing still works.
I think that the real change we need is to cleanly support PG_dirty
flags per page.  Once we do that, not only do all of the dirty inode
pageouts get fixed, but we also automatically get MAP_SHARED |
MAP_ANONYMOUS.

While we're on that subject, Linus, do you still have Andrea's patch to
propogate page writes around all shared ptes?  I noticed that Zlatko
Calusic recently re-posted it, and it looks like the sort of short-term
fix we need for this issue in 2.2 (assuming we don't have time to do a
proper PG_dirty fix).

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

  parent reply	other threads:[~1998-11-25 14:19 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       ` Linux-2.1.129 Eric W. Biederman
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               ` Stephen C. Tweedie [this message]
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=199811251419.OAA00990@dax.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=H.H.vanRiel@phys.uu.nl \
    --cc=ebiederm+eric@ccr.net \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --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