From: Mel Gorman <mgorman@suse.de>
To: Robin Holt <holt@sgi.com>
Cc: Frank Mehnert <frank.mehnert@oracle.com>,
linux-mm@kvack.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Hugh Dickins <hughd@google.com>
Subject: Re: Handling NUMA page migration
Date: Wed, 5 Jun 2013 11:10:19 +0100 [thread overview]
Message-ID: <20130605101019.GA18242@suse.de> (raw)
In-Reply-To: <20130604115807.GF3672@sgi.com>
On Tue, Jun 04, 2013 at 06:58:07AM -0500, Robin Holt wrote:
> > B) 1. allocate memory with alloc_pages()
> > 2. SetPageReserved()
> > 3. vm_mmap() to allocate a userspace mapping
> > 4. vm_insert_page()
> > 5. vm_flags |= (VM_DONTEXPAND | VM_DONTDUMP)
> > (resulting flags are VM_MIXEDMAP | VM_DONTDUMP | VM_DONTEXPAND | 0xff)
> >
> > At least the memory allocated like B) is affected by automatic NUMA page
> > migration. I'm not sure about A).
> >
> > 1. How can I prevent automatic NUMA page migration on this memory?
> > 2. Can NUMA page migration also be handled on such kind of memory without
> > preventing migration?
> >
Page migration does not expect a PageReserved && PageLRU page. The only
reserved check that is made by migration is for the zero page and that
happens in the syscall path for move_pages() which is not used by either
compaction or automatic balancing.
At some point you must have a driver that is setting PageReserved on
anonymous pages that is later encountered by automatic numa balancing
during a NUMA hinting fault. I expect this is an out-of-tree driver or
a custom kernel of some sort. Memory should be pinned by elevating the
reference count of the page, not setting PageReserved.
It's not particularly clear how you avoid hitting the same bug due to THP and
memory compaction to be honest but maybe your setup hits a steady state that
simply never hit the problem or it happens rarely and it was not identified.
--
Mel Gorman
SUSE Labs
--
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:[~2013-06-05 10:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201306040922.10235.frank.mehnert@oracle.com>
2013-06-04 11:58 ` Handling NUMA page migration Robin Holt
2013-06-04 12:14 ` Frank Mehnert
2013-06-04 13:34 ` Robin Holt
2013-06-04 14:02 ` Michal Hocko
2013-06-04 18:17 ` Frank Mehnert
2013-06-04 21:54 ` Frank Mehnert
2013-06-05 7:54 ` Michal Hocko
2013-06-05 8:34 ` Frank Mehnert
2013-06-05 8:56 ` Frank Mehnert
2013-06-05 9:10 ` Michal Hocko
2013-06-05 9:32 ` Frank Mehnert
2013-06-05 9:56 ` Michal Hocko
2013-06-05 10:22 ` Frank Mehnert
2013-06-05 11:41 ` Michal Hocko
2013-06-04 15:45 ` Jerome Glisse
2013-06-04 17:49 ` Jerome Glisse
2013-06-05 10:10 ` Mel Gorman [this message]
2013-06-05 10:35 ` Frank Mehnert
2013-06-05 12:34 ` Mel Gorman
2013-06-06 10:09 ` Frank Mehnert
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=20130605101019.GA18242@suse.de \
--to=mgorman@suse.de \
--cc=frank.mehnert@oracle.com \
--cc=holt@sgi.com \
--cc=hughd@google.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;
as well as URLs for NNTP newsgroup(s).