From: Andrea Arcangeli <andrea@suse.de>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Hugh Dickins <hugh@veritas.com>,
IWAMOTO Toshihiro <iwamoto@valinux.co.jp>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
lhms <lhms-devel@lists.sourceforge.net>
Subject: Re: [RFC] Changing COW detection to be memory hotplug friendly
Date: Thu, 10 Feb 2005 20:41:56 +0100 [thread overview]
Message-ID: <20050210194156.GQ18573@opteron.random> (raw)
In-Reply-To: <1108063004.29712.54.camel@localhost>
On Thu, Feb 10, 2005 at 11:16:44AM -0800, Dave Hansen wrote:
> We actually do that, in addition to the more active methods of capturing
> the memory that we're about to remove.
This sounds the best way to go. btw, is this a different codebase from
the one that Toshihiro is testing?
> You're right, I don't really see a problem with ignoring those pages, at
> least in the active migration code. We would, of course, like to keep
> the number of things that we depend on good faith to get migrated to a
> minimum, but things under I/O are the least of our problems.
Indeed. It's very similar to locked pages. All pages can be pinned for a
transient amount of time, either in the pte or with
PG_pinned/PG_writeback (now perhaps Hugh found a way to drop the pin on
the pte [I'm still unconvinced about that], but sure you're left with
transient pinning with PG_locked or PG_writeback).
> The only thing we might want to do is put something in the rawio code to
> look for the PG_capture pages to ensure that it gives the migration code
> a shot at them every once in a while (when I/O is not in flight,
> obviously).
If there are persistent usages PG_capture sounds a good idea. Perhaps
the whole point that Toshihiro has problem with is that there are really
persistent users that require PG_capture? He mentioned direct IO, that's
not a long time, if something core dump could be a long time.
next prev parent reply other threads:[~2005-02-10 19:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-03 3:56 [RFC] Changing COW detection to be memory hotplug friendly IWAMOTO Toshihiro
2005-02-07 21:24 ` Hugh Dickins
2005-02-08 16:26 ` Hugh Dickins
2005-02-10 7:59 ` IWAMOTO Toshihiro
2005-02-10 19:05 ` Andrea Arcangeli
2005-02-10 19:16 ` Dave Hansen
2005-02-10 19:41 ` Andrea Arcangeli [this message]
2005-02-10 20:19 ` Hugh Dickins
2005-02-10 20:40 ` Andrea Arcangeli
2005-02-11 7:23 ` Hugh Dickins
2005-02-11 8:52 ` Andrea Arcangeli
2005-02-11 13:20 ` Hugh Dickins
2005-02-14 17:41 ` Andrea Arcangeli
2005-02-14 18:36 ` Hugh Dickins
2005-02-14 21:41 ` Andrea Arcangeli
2005-02-15 3:17 ` Andrew Morton
2005-02-09 9:08 ` IWAMOTO Toshihiro
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=20050210194156.GQ18573@opteron.random \
--to=andrea@suse.de \
--cc=haveblue@us.ibm.com \
--cc=hugh@veritas.com \
--cc=iwamoto@valinux.co.jp \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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 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.