linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Kanoj Sarcar <kanoj@google.engr.sgi.com>
Cc: Christoph Rohland <hans-christoph.rohland@sap.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	linux-mm@kvack.org, linux-kernel@vger.rutgers.edu
Subject: Re: [RFC] [RFT] Shared /dev/zero mmaping feature
Date: Mon, 6 Mar 2000 22:43:04 +0000 (GMT)	[thread overview]
Message-ID: <14532.13432.760022.313353@dukat.scot.redhat.com> (raw)
In-Reply-To: <200003012009.MAA90800@google.engr.sgi.com>

Hi,

On Wed, 1 Mar 2000 12:09:11 -0800 (PST), kanoj@google.engr.sgi.com
(Kanoj Sarcar) said:

> Great, we can see what makes sense for /dev/zero wrt shmfs ...

In principle, there is no reason why we need any special support for
this sort of thing.  The swap cache already does very nearly all we
need.

The swap cache maintains links between swap locations on disk and
(potentially shared) anonymous pages in memory.  It was designed so that
even if you fork, as long as the resulting COW pages remain unchanged,
the two processes will share the same pages of physical memory or swap
no matter what.

Basically, as soon as you try to swap out an anonymous page from one
process, a swap entry is allocated and a swap cache entry is set up.
Only once the last process swaps out does the physical page in memory
get released.  Until that happens, any lookup of the swap entry from a
swapped-out process will find the page already in memory.

To make this work for shared anonymous pages, we need two changes to the
swap cache.  We need to teach the swap cache about writable anonymous
pages, and we need to be able to defer the physical writing of the page
to swap until the last reference to the swap cache frees up the page.
Do that, and shared /dev/zero maps will Just Work.

The mechanics of this are probably a little too subtle to get right for
2.4 at this stage (in particular you need to know when to write the page
back to disk: we don't have the necessary PAGE_DIRTY infrastructure in
place for anonymous pages), but I definitely think this is the right way
to do things in the long term.

--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/

  reply	other threads:[~2000-03-06 22:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-25 23:08 Kanoj Sarcar
2000-02-26 16:38 ` Linus Torvalds
2000-02-26 21:47   ` Kanoj Sarcar
2000-02-29 10:54 ` Christoph Rohland
2000-02-29 18:30   ` Kanoj Sarcar
2000-03-01 12:08     ` Christoph Rohland
2000-03-01 17:34       ` Kanoj Sarcar
2000-03-01 17:55         ` Christoph Rohland
2000-03-01 18:18           ` Kanoj Sarcar
2000-03-01 19:42             ` Christoph Rohland
2000-03-01 20:09               ` Kanoj Sarcar
2000-03-06 22:43                 ` Stephen C. Tweedie [this message]
2000-03-06 23:01                   ` Kanoj Sarcar
2000-03-08 12:02                     ` Christoph Rohland
2000-03-08 17:51                       ` Kanoj Sarcar
2000-03-08 18:35                         ` Christoph Rohland
2000-03-08 18:48                           ` Linus Torvalds
2000-03-08 18:57                           ` Kanoj Sarcar
2000-03-09 18:15                             ` Christoph Rohland

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=14532.13432.760022.313353@dukat.scot.redhat.com \
    --to=sct@redhat.com \
    --cc=hans-christoph.rohland@sap.com \
    --cc=kanoj@google.engr.sgi.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --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