From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, lhms-devel@lists.sourceforge.net,
Hirokazu Takahashi <taka@valinux.co.jp>,
Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview
Date: Wed, 05 Apr 2006 10:46:02 -0400 [thread overview]
Message-ID: <1144248362.5203.22.camel@localhost.localdomain> (raw)
In-Reply-To: <20060404065739.24532.95451.sendpatchset@schroedinger.engr.sgi.com>
On Mon, 2006-04-03 at 23:57 -0700, Christoph Lameter wrote:
> Swapless Page migration
>
> Currently page migration is depending on the ability to assign swap entries
> to pages. This means that page migration will not work without swap although
> that swap space is never used.
>
> This patchset removes that dependency by introducing a special type of
> swap entry that encodes a pfn number of the page being migrated. If that
> swap pte is encountered then do_swap_page() will simply wait for the page
> to become unlocked again (meaning page migration is complete) and then refetch
> the pte. The special type of swap entry is only in use while the page to be
> migrated is locked and therefore we can hopefully get away with just a few
> supporting functions.
>
> To some extend this covers the same ground as Lee's and Marcelo's migration
> cache. However, I hope that this approach simplifies things without opening
> up any holes. Please check.
>
Christoph:
Does this approach still allow "migrate-on-fault" for anon pages?
Especially, in the case where the migrating page has >1 pte referencing
it? How will the fault handler find all of the pte's referencing the
old page? Actually, I don't think we'd want to burden the task whose
fault caused the migration with finding and replacing and replacing all
pte's referecing the old page. Using a real cache, this isn't a problem
because we replace the old page with a new one in the cache, and the
cache ptes reference the cache entry. Tasks are free to fault in a real
pte for the new page at any time. I'd hate to lose this capability. I
believe that this is one of the reasons that Marcello used a real idr-
based cache for the migration cache.
Lee
--
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 prev parent reply other threads:[~2006-04-05 14:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-04 6:57 [RFC 0/6] Swapless Page Migration V1: Overview Christoph Lameter
2006-04-04 6:57 ` [RFC 1/6] Swapless V1: try_to_unmap() - Rename ignrefs to "migration" Christoph Lameter
2006-04-04 6:57 ` [RFC 2/6] Swapless V1: Add SWP_TYPE_MIGRATION Christoph Lameter
2006-04-04 11:04 ` KAMEZAWA Hiroyuki
2006-04-04 6:57 ` [RFC 3/6] Swapless V1: try_to_unmap() - Create migration entries Christoph Lameter
2006-04-04 6:58 ` [RFC 4/6] Swapless V1: remove migration ptes Christoph Lameter
2006-04-04 6:58 ` [RFC 5/6] Swapless V1: Rip out swap migration code Christoph Lameter
2006-04-04 10:37 ` KAMEZAWA Hiroyuki
2006-04-04 15:06 ` Christoph Lameter
2006-04-05 1:06 ` KAMEZAWA Hiroyuki
2006-04-05 2:45 ` Christoph Lameter
2006-04-05 3:33 ` KAMEZAWA Hiroyuki
2006-04-05 3:47 ` Christoph Lameter
2006-04-05 4:07 ` KAMEZAWA Hiroyuki
2006-04-04 6:58 ` [RFC 6/6] Swapless V1: Revise main migration logic Christoph Lameter
2006-04-04 10:58 ` KAMEZAWA Hiroyuki
2006-04-04 14:24 ` Christoph Lameter
2006-04-05 14:46 ` Lee Schermerhorn [this message]
2006-04-05 16:28 ` [Lhms-devel] [RFC 0/6] Swapless Page Migration V1: Overview Christoph Lameter
2006-04-05 16:58 ` Lee Schermerhorn
2006-04-05 17:43 ` Christoph Lameter
2006-04-05 18:52 ` Lee Schermerhorn
2006-04-05 18:17 ` Some ideas on lazy migration with swapless migration Christoph Lameter
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=1144248362.5203.22.camel@localhost.localdomain \
--to=lee.schermerhorn@hp.com \
--cc=clameter@sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-mm@kvack.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=taka@valinux.co.jp \
/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.