linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux-foundation.org>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mel@csn.ul.ie>, Wu Fengguang <fengguang.wu@intel.com>,
	Jun'ichi Nomura <j-nomura@ce.jp.nec.com>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/7] hugetlb: pin oldpage in page migration
Date: Tue, 6 Jul 2010 10:54:38 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1007061050320.4938@router.home> (raw)
In-Reply-To: <1278049646-29769-6-git-send-email-n-horiguchi@ah.jp.nec.com>

On Fri, 2 Jul 2010, Naoya Horiguchi wrote:

> This patch introduces pinning the old page during page migration
> to avoid freeing it before we complete copying.

The old page is already pinned due to the reference count that is taken
when the page is put onto the list of pages to be migrated. See
do_move_pages() f.e.

Huge pages use a different scheme?

> This race condition can happen for privately mapped or anonymous hugepage.

It cannot happen unless you come up with your own scheme of managing pages
to be migrated and bypass migrate_pages(). There you should take the
refcount.

>  	/*
> +	 * It's reasonable to pin the old page until unmapping and copying
> +	 * complete, because when the original page is an anonymous hugepage,
> +	 * it will be freed in try_to_unmap() due to the fact that
> +	 * all references of anonymous hugepage come from mapcount.
> +	 * Although in the other cases no problem comes out without pinning,
> +	 * it looks logically correct to do it.
> +	 */
> +	get_page(page);
> +
> +	/*

Its already pinned. Dont do this. migrate_pages() relies on the caller
having pinned the page already.

--
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>

  parent reply	other threads:[~2010-07-06 15:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-02  5:47 [PATCH 0/7] hugepage migration Naoya Horiguchi
2010-07-02  5:47 ` [PATCH 1/7] hugetlb: add missing unlock in avoidcopy path in hugetlb_cow() Naoya Horiguchi
2010-07-02  8:31   ` Andi Kleen
2010-07-05  8:44     ` Naoya Horiguchi
2010-07-07 22:17   ` Andi Kleen
2010-07-02  5:47 ` [PATCH 2/7] hugetlb, HWPOISON: move PG_HWPoison bit check Naoya Horiguchi
2010-07-02  5:47 ` [PATCH 3/7] hugetlb: add allocate function for hugepage migration Naoya Horiguchi
2010-07-02  9:08   ` Andi Kleen
2010-07-05  8:46     ` Naoya Horiguchi
2010-07-05  9:28       ` Andi Kleen
2010-07-02  5:47 ` [PATCH 4/7] hugetlb: add hugepage check in mem_cgroup_{register,end}_migration() Naoya Horiguchi
2010-07-02  9:11   ` Andi Kleen
2010-07-02  5:47 ` [PATCH 5/7] hugetlb: pin oldpage in page migration Naoya Horiguchi
2010-07-05  9:45   ` Andi Kleen
2010-07-06 15:54   ` Christoph Lameter [this message]
2010-07-07  6:40     ` Naoya Horiguchi
2010-07-02  5:47 ` [PATCH 6/7] hugetlb: hugepage migration core Naoya Horiguchi
2010-07-05  9:59   ` Andi Kleen
2010-07-06  3:33     ` Naoya Horiguchi
2010-07-06  7:13       ` Andi Kleen
2010-07-07  6:05         ` Naoya Horiguchi
2010-07-07  9:27           ` Andi Kleen
2010-07-08  5:44             ` Naoya Horiguchi
2010-07-08  6:49               ` Andi Kleen
2010-07-06 16:02       ` Christoph Lameter
2010-07-07  6:44         ` Naoya Horiguchi
2010-07-06 16:00   ` Christoph Lameter
2010-07-07  6:45     ` Naoya Horiguchi
2010-07-02  5:47 ` [PATCH 7/7] hugetlb, HWPOISON: soft offlining for hugepage Naoya Horiguchi
2010-07-05 10:28   ` Andi Kleen
2010-07-02  8:30 ` [PATCH 0/7] hugepage migration Andi Kleen
2010-07-05  8:44   ` Naoya Horiguchi

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=alpine.DEB.2.00.1007061050320.4938@router.home \
    --to=cl@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=fengguang.wu@intel.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=n-horiguchi@ah.jp.nec.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).