mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kimball Murray" <kimball.murray@gmail.com>
To: "Andi Kleen" <ak@suse.de>
Cc: "Nick Piggin" <nickpiggin@yahoo.com.au>,
	linux-kernel@vger.kernel.org, akpm@digeo.com
Subject: Re: [Feature] x86_64 page tracking for Stratus servers
Date: Wed, 6 Sep 2006 11:10:04 -0400	[thread overview]
Message-ID: <bbe04eb10609060810j70562e3dt6a87067d95bc883e@mail.gmail.com> (raw)
In-Reply-To: <200609060936.19268.ak@suse.de>

On 9/6/06, Andi Kleen <ak@suse.de> wrote:
>
> > Silly question, why can't you do all this from stop_machine_run context (or
> > your SMI) that doesn't have to worry about other CPUs dirtying memory?
>
> Because that would be too slow for continuous mirroring.
>
> You can't go through 10+GB of virtual memory (or more with shared
> memory because the scan has to be virtual) in an interrupt.
>
> The only sane way is to do it continuously.

That's exactly right on all counts.  We can "harvest" dirty pages in a
continuous fashion, as a background task.  But when we finally decide
to dive in to machine blackout for the final copy, we need to ensure
that the blackout is as short as possible.  Toward that goal, we have
built a sort of DMA engine that can move pages over the backplane to
the spare cpu/memory module without interfering (much) with the active
module's activities.  We continue doing this until the number of pages
for final copy is small enough that we can be sure the final blackout
copy will take a sufficiently short time.

And you're right about the virtual scan as well.  Trouble is, it's a
potentially unbounded scan.  With the right machine load, we can find
ourselves in a state where it takes so long to scan all the page
tables that the pages are all dirty again before we start the next
pass. For this situation we have two choices.  We can either give up
and dive into the blackout passing a dirty list that basically
includes all of memory (long blackout time!), or we can continue
scanning for a long time, waiting and hoping the machine load will
decrease to a point where are target number of dirty pages is reached.
 This sort of thing will always be a problem with a software solution.

-kimball

  parent reply	other threads:[~2006-09-06 15:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-05 17:34 Kimball Murray
2006-09-05 17:40 ` Arjan van de Ven
2006-09-05 18:38   ` Kimball Murray
2006-09-05 20:48     ` Andi Kleen
2006-09-05 17:56 ` Dave Hansen
2006-09-05 18:50   ` Kimball Murray
2006-09-05 18:16 ` Andi Kleen
2006-09-06  6:38 ` Nick Piggin
2006-09-06  7:36   ` Andi Kleen
2006-09-06  9:36     ` Nick Piggin
2006-09-06 15:10     ` Kimball Murray [this message]
2006-09-06 14:10   ` Kimball Murray

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=bbe04eb10609060810j70562e3dt6a87067d95bc883e@mail.gmail.com \
    --to=kimball.murray@gmail.com \
    --cc=ak@suse.de \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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

all inboxes | Powered by JetHome®