All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-mm <linux-mm@kvack.org>
Subject: Re: Linux-2.1.129..
Date: 25 Nov 1998 15:07:39 -0600	[thread overview]
Message-ID: <m1u2znbhwj.fsf@flinx.ccr.net> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of "Wed, 25 Nov 1998 14:19:28 GMT"

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

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


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

What do you consider a proper PG_dirty fix?

I have been working on it (what I would call a PG_dirty fix) and have
most thing working but my code has a lot of policy questions still to
answer.



But as far as MAP_SHARED | MAP_ANONYMOUS to retain our current
swapping model (of never rewriting a swap page), and for swapoff
support we need the ability to change which swap page all of the pages
are associated with.

There are 2 ways to do this.  
1) Implement it like SYSV shared mem.
2) Just maintain vma structs for the memory, with vma_next_share used!
   Then when we allocate a new swap page we can walk the
   *vm_area_struct's to find the page_tables that need to be updated.

   The real tricky case to get right is simulaneous COW & SOW.
   SOW == Share On Write.

  The question right now is where do we anchor the vma_next_share
  linked list, as we don't have an inode.


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-25 21:23 UTC|newest]

Thread overview: 30+ 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               ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 21:07                 ` Eric W. Biederman [this message]
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
1998-11-19 19:22 Linux-2.1.129 David S. Miller

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=m1u2znbhwj.fsf@flinx.ccr.net \
    --to=ebiederm+eric@ccr.net \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.