[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1008160707420.11420@router.home>
Date: Mon, 16 Aug 2010 07:19:58 -0500 (CDT)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
cc: Andi Kleen <andi@...stfloor.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@....ul.ie>,
Wu Fengguang <fengguang.wu@...el.com>,
Jun'ichi Nomura <j-nomura@...jp.nec.com>,
linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/9] Hugepage migration (v2)
On Mon, 16 Aug 2010, Naoya Horiguchi wrote:
> In my understanding, in current code "other processors increasing refcount
> during migration" can happen both in non-hugepage direct I/O and in hugepage
> direct I/O in the similar way (i.e. get_user_pages_fast() from dio_refill_pages()).
> So I think there is no specific problem to hugepage.
> Or am I missing your point?
With a single page there is the check of the refcount during migration
after all the references have been removed (at that point the page is no
longer mapped by any process and direct iO can no longer be
initiated without a page fault.
I see that you are running try_to_unmap() from unmap_and_move_huge_page().
I dont see a patch adding huge page support to try_to_unmap though. How
does this work?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists