linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

             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