linux-kernel - Re: [PATCH v5 09/11] mm: mempolicy: mbind and migrate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58FA2C9C.5030107@cs.rutgers.edu>
Date:   Fri, 21 Apr 2017 11:00:28 -0500
From:   Zi Yan <zi.yan@...rutgers.edu>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>
CC:     Zi Yan <zi.yan@...t.com>, n-horiguchi@...jp.nec.com,
        kirill.shutemov@...ux.intel.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, akpm@...ux-foundation.org, minchan@...nel.org,
        vbabka@...e.cz, mgorman@...hsingularity.net, mhocko@...nel.org,
        dnellans@...dia.com
Subject: Re: [PATCH v5 09/11] mm: mempolicy: mbind and migrate_pages support
 thp migration



Anshuman Khandual wrote:
> On 04/21/2017 02:17 AM, Zi Yan wrote:
>> From: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
>>
>> This patch enables thp migration for mbind(2) and migrate_pages(2).
>>
>> Signed-off-by: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
>> ---
>> ChangeLog v1 -> v2:
>> - support pte-mapped and doubly-mapped thp
>> ---
>>  mm/mempolicy.c | 108 +++++++++++++++++++++++++++++++++++++++++----------------
>>  1 file changed, 79 insertions(+), 29 deletions(-)
> 
> Snip
> 
>> @@ -981,7 +1012,17 @@ static struct page *new_node_page(struct page *page, unsigned long node, int **x
>>  	if (PageHuge(page))
>>  		return alloc_huge_page_node(page_hstate(compound_head(page)),
>>  					node);
>> -	else
>> +	else if (thp_migration_supported() && PageTransHuge(page)) {
>> +		struct page *thp;
>> +
>> +		thp = alloc_pages_node(node,
>> +			(GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
>> +			HPAGE_PMD_ORDER);
>> +		if (!thp)
>> +			return NULL;
>> +		prep_transhuge_page(thp);
>> +		return thp;
>> +	} else
>>  		return __alloc_pages_node(node, GFP_HIGHUSER_MOVABLE |
>>  						    __GFP_THISNODE, 0);
>>  }
>> @@ -1147,6 +1188,15 @@ static struct page *new_page(struct page *page, unsigned long start, int **x)
>>  	if (PageHuge(page)) {
>>  		BUG_ON(!vma);
>>  		return alloc_huge_page_noerr(vma, address, 1);
>> +	} else if (thp_migration_supported() && PageTransHuge(page)) {
>> +		struct page *thp;
>> +
>> +		thp = alloc_hugepage_vma(GFP_TRANSHUGE, vma, address,
>> +					 HPAGE_PMD_ORDER);
>> +		if (!thp)
>> +			return NULL;
>> +		prep_transhuge_page(thp);
>> +		return thp;
> 
> GFP flags in both these new page allocation functions should be the same.
> Does alloc_hugepage_vma() will eventually call page allocation with the
> following flags.
> 
> (GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM

Sure. This is equivalent to (GFP_TRANSHUGE_LIGHT | __GFP_THISNODE),
which I am going to use.

-- 
Best Regards,
Yan Zi


Download attachment "signature.asc" of type "application/pgp-signature" (538 bytes)