[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50BC13EB.1050009@cn.fujitsu.com>
Date: Mon, 03 Dec 2012 10:52:27 +0800
From: Lin Feng <linfeng@...fujitsu.com>
To: Mel Gorman <mgorman@...e.de>
CC: Andrew Morton <akpm@...ux-foundation.org>, viro@...iv.linux.org.uk,
bcrl@...ck.org, kamezawa.hiroyu@...fujitsu.com, mhocko@...e.cz,
hughd@...gle.com, cl@...ux.com, minchan@...nel.org,
isimatu.yasuaki@...fujitsu.com, laijs@...fujitsu.com,
wency@...fujitsu.com, tangchen@...fujitsu.com,
linux-fsdevel@...r.kernel.org, linux-aio@...ck.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG REPORT] [mm-hotplug, aio] aio ring_pages can't be offlined
On 11/30/2012 07:00 PM, Mel Gorman wrote:
>>
>> Well, that's a fairly low-level implementation detail. A more typical
>> approach would be to add a new get_user_pages_non_movable() or such.
>> That would probably have the same signature as get_user_pages(), with
>> one additional argument. Then get_user_pages() becomes a one-line
>> wrapper which passes in a particular value of that argument.
>>
>
> That is going in the direction that all pinned pages become MIGRATE_UNMOVABLE
> allocations. That will impact THP availability by increasing the number
> of MIGRATE_UNMOVABLE blocks that exist and it would hit every user --
> not just those that care about ZONE_MOVABLE.
>
> I'm likely to NAK such a patch if it's only about node hot-remove because
> it's much more of a corner case than wanting to use THP.
>
> I would prefer if get_user_pages() checked if the page it was about to
> pin was in ZONE_MOVABLE and if so, migrate it at that point before it's
> pinned. It'll be expensive but will guarantee ZONE_MOVABLE availability
> if that's what they want. The CMA people might also want to take
> advantage of this if the page happened to be in the MIGRATE_CMA
> pageblock.
>
hi Mel,
Thanks for your suggestion.
My initial idea is also to restrict the impact as little as possible so
migrate such pages as we need.
But even to such "going to pin pages", most of them are going to be released
soon, so deal with them all in the same way is really *expensive*.
May be we do have to find another way that makes everybody happy :)
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