From: mel@skynet.ie (Mel Gorman)
To: Ross Biro <rossb@google.com>
Cc: Dave Hansen <haveblue@us.ibm.com>,
linux-mm@kvack.org, Mel Gorman <MELGOR@ie.ibm.com>
Subject: Re: RFC/POC Make Page Tables Relocatable
Date: Fri, 26 Oct 2007 18:11:19 +0100 [thread overview]
Message-ID: <20071026171119.GC19443@skynet.ie> (raw)
In-Reply-To: <d43160c70710260951q351a6864ye5bb49e1b8a96aa3@mail.gmail.com>
On (26/10/07 12:51), Ross Biro didst pronounce:
> On 10/26/07, Mel Gorman <mel@skynet.ie> wrote:
> > I suspect this might be overkill from a memory fragmentation
> > perspective. When grouping pages by mobility, page table pages are
> > currently considered MIGRATE_UNMOVABLE. From what I have seen, they are
>
> I may be being dense, but the page migration code looks to me like it
> just moves pages in a process from one node to another node with no
> effort to touch the page tables.
Exactly, if it was able to move arbitrary pagetable pages too, it would
be useful. Page migrations traditional case is to move pages between
nodes but memory hot-remove also uses it to move pages around a zone and
there has been at least one other case which I'm coming to.
> It would be easy to hook the code I
> wrote into the page migration code, what I don't understand is when
> the page tables should be migrated?
>From an external fragmentation point of view, they would be moved when a
high-order allocation failued. Patches exist that do this sort of thing
under the title "Memory Compaction" but they are not merged because they
don't have a demonstratable use-case yet[1].
> Only when the whole process is
> being migrated? When all the pages pointed to a page table are being
> migrated? When any page pointed to by the page table is being
> migrated?
>
If it was external fragmentation you were dealing with, a pagetable apge
would be moved once it was found to be preventing a high-order (e.gh.
hugepage) allocation from succeeding.
[1] Intuitively, the use case would be that a hugepage allocation
happened faster when moving pages around than reclaiming them.
This situation does not happen often enough to justify the
complexity of the code though.
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
prev parent reply other threads:[~2007-10-26 17:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 15:16 RFC/POC Make Page Tables Relocatable Ross Biro
2007-10-25 16:46 ` Dave Hansen
2007-10-25 17:40 ` Ross Biro
2007-10-25 18:08 ` Dave Hansen
2007-10-25 18:44 ` Ross Biro
2007-10-25 18:47 ` Dave Hansen
2007-10-25 19:23 ` Dave Hansen
2007-10-25 19:53 ` Ross Biro
2007-10-25 19:56 ` Dave Hansen
2007-10-25 19:58 ` Ross Biro
2007-10-25 20:15 ` Dave Hansen
2007-10-25 20:00 ` Dave Hansen
2007-10-25 20:10 ` Ross Biro
2007-10-25 20:20 ` Dave Hansen
2007-10-26 16:10 ` Mel Gorman
2007-10-26 16:51 ` Ross Biro
2007-10-26 17:11 ` Mel Gorman [this message]
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=20071026171119.GC19443@skynet.ie \
--to=mel@skynet.ie \
--cc=MELGOR@ie.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-mm@kvack.org \
--cc=rossb@google.com \
/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;
as well as URLs for NNTP newsgroup(s).