[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <513728AD.6020307@cn.fujitsu.com>
Date: Wed, 06 Mar 2013 19:29:49 +0800
From: Lin Feng <linfeng@...fujitsu.com>
To: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
CC: akpm@...ux-foundation.org, mgorman@...e.de, bcrl@...ck.org,
viro@...iv.linux.org.uk, khlebnikov@...nvz.org, walken@...gle.com,
kamezawa.hiroyu@...fujitsu.com, minchan@...nel.org,
riel@...hat.com, rientjes@...gle.com, wency@...fujitsu.com,
laijs@...fujitsu.com, tangchen@...fujitsu.com,
guz.fnst@...fujitsu.com, jiang.liu@...wei.com, zab@...hat.com,
jmoyer@...hat.com, linux-mm@...ck.org, linux-aio@...ck.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
m.szyprowski@...sung.com
Subject: Re: [PATCH V3 1/2] mm: hotplug: implement non-movable version of
get_user_pages() called get_user_pages_non_movable()
Hi Yasuaki,
On 03/06/2013 03:48 PM, Yasuaki Ishimatsu wrote:
> Hi Lin,
>
> IMHO, current implementation depends on luck. So even if system has
> many non movable memory, get_user_pages_non_movable() may not allocate
> non movable memory.
Sorry, I'm not quite understand here, since the to be pinned pages are
never pinned before, the migration successful probability is quite high,
not just depends on luck.
>
> At following thread, Marek Szyprowski implemented similar feature which
> allocates non movable memory by "get_user_pages()".
>
> https://lkml.org/lkml/2013/3/5/44
>
> I think Marek's way is better.
I think the two versions of get_user_pages() are not that great and one
I can see is that Marek's patchset adding new flag to instruct the page
allocation while I'm not sure if that approach is proper since it touches
the core page allocation codes.
Besides in Marek's version we also have to patch every place if we want to
get around migration failure caused by GUP long pinned pages unless
we want GUP fall into getting all pages from non movable zones.
As Mel suggested before adding a migrate callback for such pages may be
another approach, but we also have to distinguish the long-time pin
and short-time pin while which is not expectable beforehand.
So what we can do to improve is to migrate the pinned pages by GUP just
the time we perform the migration caused by memory hotplug or cma people
so that nobody cases if the page is long-time pinned or not :)
But is that feasible to migrate a being pinned page ?
thanks,
linfeng
--
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