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 0/9] Hugepage migration (v2)
Date: Wed, 11 Aug 2010 08:09:59 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1008110806070.673@router.home> (raw)
In-Reply-To: <1281432464-14833-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On Tue, 10 Aug 2010, Naoya Horiguchi wrote:
> There were two points of issue.
>
> * Dividing hugepage migration functions from original migration code.
> This is to avoid complexity.
> In present version, some high level migration routines are defined to handle
> hugepage, but some low level routines (such as migrate_copy_page() etc.)
> are shared with original migration code in order not to increase duplication.
I hoped that we can avoid the branching for taking stuff off the lru and
put pages back later to the lru. Seems that we still do that. Can be
refactor the code in such a way that the lru handling cleanly isolates?
There are now multiple use cases for migration that could avoid LRU
handling even for PAGE_SIZE pages.
> * Locking problem between direct I/O and hugepage migration
> As a result of digging the race between hugepage I/O and hugepage migration,
> (where hugepage I/O can be seen only in direct I/O,)
> I noticed that without additional locking we can avoid this race condition
> because in direct I/O we can get whether some subpages are under I/O or not
> from reference count of the head page and hugepage migration safely fails
> if some references remain. So no data lost should occurs on the migration
> concurrent with direct I/O.
Can you also avoid refcounts being increased during migration? The page
lock is taken for the PAGE_SIZEd migration case. Can direct I/O be stopped
by taking the page lock on the head page? If not then races can still
occur.
WARNING: multiple messages have this Message-ID (diff)
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 0/9] Hugepage migration (v2)
Date: Wed, 11 Aug 2010 08:09:59 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1008110806070.673@router.home> (raw)
In-Reply-To: <1281432464-14833-1-git-send-email-n-horiguchi@ah.jp.nec.com>
On Tue, 10 Aug 2010, Naoya Horiguchi wrote:
> There were two points of issue.
>
> * Dividing hugepage migration functions from original migration code.
> This is to avoid complexity.
> In present version, some high level migration routines are defined to handle
> hugepage, but some low level routines (such as migrate_copy_page() etc.)
> are shared with original migration code in order not to increase duplication.
I hoped that we can avoid the branching for taking stuff off the lru and
put pages back later to the lru. Seems that we still do that. Can be
refactor the code in such a way that the lru handling cleanly isolates?
There are now multiple use cases for migration that could avoid LRU
handling even for PAGE_SIZE pages.
> * Locking problem between direct I/O and hugepage migration
> As a result of digging the race between hugepage I/O and hugepage migration,
> (where hugepage I/O can be seen only in direct I/O,)
> I noticed that without additional locking we can avoid this race condition
> because in direct I/O we can get whether some subpages are under I/O or not
> from reference count of the head page and hugepage migration safely fails
> if some references remain. So no data lost should occurs on the migration
> concurrent with direct I/O.
Can you also avoid refcounts being increased during migration? The page
lock is taken for the PAGE_SIZEd migration case. Can direct I/O be stopped
by taking the page lock on the head page? If not then races can still
occur.
--
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:[~2010-08-11 13:10 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-10 9:27 [PATCH 0/9] Hugepage migration (v2) Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 1/9] HWPOISON, hugetlb: move PG_HWPoison bit check Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-18 0:18 ` Wu Fengguang
2010-08-18 0:18 ` Wu Fengguang
2010-08-19 7:55 ` Naoya Horiguchi
2010-08-19 7:55 ` Naoya Horiguchi
2010-08-19 9:28 ` Wu Fengguang
2010-08-19 9:28 ` Wu Fengguang
2010-08-23 9:24 ` Naoya Horiguchi
2010-08-23 9:24 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 2/9] hugetlb: add allocate function for hugepage migration Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-17 6:51 ` David Rientjes
2010-08-17 6:51 ` David Rientjes
2010-08-18 3:02 ` Naoya Horiguchi
2010-08-18 3:02 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 3/9] hugetlb: rename hugepage allocation functions Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 4/9] hugetlb: redefine hugepage copy functions Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 5/9] hugetlb: hugepage migration core Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 6/9] HWPOISON, hugetlb: soft offlining for hugepage Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 7/9] HWPOISON, hugetlb: fix unpoison " Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-10 9:27 ` [PATCH 8/9] page-types.c: fix name of unpoison interface Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-19 1:24 ` Wu Fengguang
2010-08-19 1:24 ` Wu Fengguang
2010-08-10 9:27 ` [PATCH 9/9] hugetlb: add corrupted hugepage counter Naoya Horiguchi
2010-08-10 9:27 ` Naoya Horiguchi
2010-08-19 1:57 ` Wu Fengguang
2010-08-19 1:57 ` Wu Fengguang
2010-08-24 3:01 ` Naoya Horiguchi
2010-08-24 3:01 ` Naoya Horiguchi
2010-08-24 3:08 ` Wu Fengguang
2010-08-24 3:08 ` Wu Fengguang
2010-08-11 13:09 ` Christoph Lameter [this message]
2010-08-11 13:09 ` [PATCH 0/9] Hugepage migration (v2) Christoph Lameter
2010-08-12 7:53 ` Naoya Horiguchi
2010-08-12 7:53 ` Naoya Horiguchi
2010-08-12 7:57 ` [RFC] [PATCH 1/4] hugetlb: prepare exclusion control functions for hugepage Naoya Horiguchi
2010-08-12 7:57 ` Naoya Horiguchi
2010-08-12 7:59 ` [RFC] [PATCH 2/4] dio: add page locking for direct I/O Naoya Horiguchi
2010-08-12 7:59 ` Naoya Horiguchi
2010-08-12 13:42 ` Jeff Moyer
2010-08-12 13:42 ` Jeff Moyer
2010-08-16 2:07 ` Naoya Horiguchi
2010-08-16 2:07 ` Naoya Horiguchi
2010-08-16 7:21 ` Andi Kleen
2010-08-16 7:21 ` Andi Kleen
2010-08-16 13:20 ` Jeff Moyer
2010-08-16 13:20 ` Jeff Moyer
2010-08-17 8:17 ` Naoya Horiguchi
2010-08-17 8:17 ` Naoya Horiguchi
2010-08-17 13:46 ` Jeff Moyer
2010-08-17 13:46 ` Jeff Moyer
2010-08-17 14:21 ` Andi Kleen
2010-08-17 14:21 ` Andi Kleen
2010-08-17 16:41 ` Christoph Lameter
2010-08-17 16:41 ` Christoph Lameter
2010-08-12 8:00 ` [PATCH 3/4] HWPOISON: replace locking functions into hugepage variants Naoya Horiguchi
2010-08-12 8:00 ` Naoya Horiguchi
2010-08-12 8:00 ` [PATCH 4/4] correct locking functions of hugepage migration routine Naoya Horiguchi
2010-08-12 8:00 ` Naoya Horiguchi
2010-08-13 12:47 ` [PATCH 0/9] Hugepage migration (v2) Christoph Lameter
2010-08-13 12:47 ` Christoph Lameter
2010-08-16 9:19 ` Naoya Horiguchi
2010-08-16 9:19 ` Naoya Horiguchi
2010-08-16 12:19 ` Christoph Lameter
2010-08-16 12:19 ` Christoph Lameter
2010-08-17 2:37 ` Naoya Horiguchi
2010-08-17 2:37 ` Naoya Horiguchi
2010-08-17 8:18 ` Naoya Horiguchi
2010-08-17 8:18 ` Naoya Horiguchi
2010-08-17 9:40 ` Andi Kleen
2010-08-17 9:40 ` Andi Kleen
2010-08-18 7:32 ` Naoya Horiguchi
2010-08-18 7:32 ` Naoya Horiguchi
2010-08-18 7:46 ` Andi Kleen
2010-08-18 7:46 ` Andi Kleen
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.1008110806070.673@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 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.