From: Jim Paradis <jparadis@redhat.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] Dirty page tracking & on-the-fly memory mirroring
Date: Fri, 31 Jul 2009 20:44:45 -0400 [thread overview]
Message-ID: <4A738FFD.8020705@redhat.com> (raw)
Following are two patches against 2.6.31-rc3 which implement dirty page
tracking and on-the-fly memory mirroring. The idea is to be able to
copy the entire physical memory over to another processor node or memory
module while the system is running. Stratus makes use of this
functionality to bring a new partner node online. Supercomputer
applications can use this to allow a failing module to gracefully bring
up and cut over to a hot spare.
The overall method is as follows: An initial scan is made to copy over
all of physical memory. During that time, some pages may have been
dirtied so we have to go back and copy them again. Lather, rinse,
repeat for a set number of passes. Finally, quiesce the system so that
we can copy over the last of the dirtied pages. Note that we only want
to copy over pages that have been RE-dirtied since our last scan. If a
page was dirty in the first scan but no *additional* data has been
written to it, there's no need to copy it over again.
The first patch implements dirty page tracking and re-dirty detection.
We use one of the programmer bits in the PTE to implement a "soft dirty"
bit. In the VM subsystem, all tests for dirty pages check the logical
OR of the hardware dirty bit and the "soft dirty" bit; if either one is
set the page is considered "dirty" for VM purposes. To speed up the
scanning passes this patch also implements a bitmapped side-list of
dirty physical pages.
The second patch is a reference implementation of a memory-mirroring
module ("pagesync"). It is the same code that Stratus uses minus some
hardware-specific bits. This module scans through physical memory,
clearing the hardware dirty bit of any dirty page and setting the
software dirty bit. If a dirty page has the *hardware* dirty bit set on
a subsequent scan, we know that the page has been re-dirtied and it is a
candidate for being copied again.
Jim Paradis
Red Hat Stratus onsite partner rep
--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2009-08-01 0:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-01 0:44 Jim Paradis [this message]
2009-08-01 5:13 ` Chris Friesen
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=4A738FFD.8020705@redhat.com \
--to=jparadis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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