[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51234C12.4020404@cn.fujitsu.com>
Date: Tue, 19 Feb 2013 17:55:30 +0800
From: Lin Feng <linfeng@...fujitsu.com>
To: Mel Gorman <mgorman@...e.de>
CC: Andrew Morton <akpm@...ux-foundation.org>, 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,
isimatu.yasuaki@...fujitsu.com, wency@...fujitsu.com,
laijs@...fujitsu.com, jiang.liu@...wei.com, linux-mm@...ck.org,
linux-aio@...ck.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mm: hotplug: implement non-movable version of get_user_pages()
called get_user_pages_non_movable()
Hi Mel,
On 02/18/2013 11:17 PM, Mel Gorman wrote:
>>> > > <SNIP>
>>> > >
>>> > > result. It's a little clumsy but the memory hot-remove failure message
>>> > > could list what applications have pinned the pages that cannot be removed
>>> > > so the administrator has the option of force-killing the application. It
>>> > > is possible to discover what application is pinning a page from userspace
>>> > > but it would involve an expensive search with /proc/kpagemap
>>> > >
>>>>> > >>> + if (migrate_pre_flag && !isolate_err) {
>>>>> > >>> + ret = migrate_pages(&pagelist, alloc_migrate_target, 1,
>>>>> > >>> + false, MIGRATE_SYNC, MR_SYSCALL);
>>> > >
>>> > > The conversion of alloc_migrate_target is a bit problematic. It strips
>>> > > the __GFP_MOVABLE flag and the consequence of this is that it converts
>>> > > those allocation requests to MIGRATE_UNMOVABLE. This potentially is a large
>>> > > number of pages, particularly if the number of get_user_pages_non_movable()
>>> > > increases for short-lived pins like direct IO.
>> >
>> > Sorry, I don't quite understand here neither. If we use the following new
>> > migration allocation function as you said, the increasing number of
>> > get_user_pages_non_movable() will also lead to large numbers of MIGRATE_UNMOVABLE
>> > pages. What's the difference, do I miss something?
>> >
> The replacement function preserves the __GFP_MOVABLE flag. It cannot use
> ZONE_MOVABLE but otherwise the newly allocated page will be grouped with
> other movable pages.
Ah, got it " But GFP_MOVABLE is not only a zone specifier but also an allocation policy.".
Could I clear __GFP_HIGHMEM flag in alloc_migrate_target depending on private parameter so
that we can keep MIGRATE_UNMOVABLE policy also allocate page none movable zones with little
change?
Does that approach work? Otherwise I have to follow your suggestion.
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