linux-kernel - Re: [RFC] mm/compaction: ignore block suitable after check large free page

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <129003b1-bf1e-db03-6117-59657d2ae0b1@suse.cz>
Date:   Mon, 13 Mar 2017 10:51:35 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Yisheng Xie <xieyisheng1@...wei.com>, akpm@...ux-foundation.org,
        mhocko@...e.com, mgorman@...hsingularity.net,
        iamjoonsoo.kim@....com, rientjes@...gle.com, minchan@...nel.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        guohanjun@...wei.com, qiuxishi@...wei.com, liubo95@...wei.com
Subject: Re: [RFC] mm/compaction: ignore block suitable after check large free
 page

On 03/10/2017 10:53 AM, Yisheng Xie wrote:
> Hi Vlastimil,
> 
> Thanks for comment.
> On 2017/3/10 15:30, Vlastimil Babka wrote:
>> On 03/10/2017 05:20 AM, Yisheng Xie wrote:
>>> If the migrate target is a large free page and we ignore suitable,
>>> it may not good for defrag. So move the ignore block suitable after
>>> check large free page.
>>
>> Right. But in practice I expect close to no impact, because direct
>> compaction shouldn't have to be called if there's a >=pageblock_order
>> page already available.
>>
> Maybe you are right and this change is just based on logical analyses.

I'm not opposing the change, it might be better for future-proofing the
function, just pointing out that it most likely won't have any visible
effect right now.

> Presently, only in direct compaction, we increase the compaction priority,
> and ignore suitable at MIN_COMPACT_PRIORITY. I have a silly question, can
> we do the similar thing in kcompactd? maybe by doing most work in kcompactd,
> we can get better perf of slow path.

That would need a very good evaluation at the very least. Migrating
pages into pageblocks other than movable ones brings the danger of later
unmovable/reclaimable allocations having to fallback to movable
pageblocks and causing permanent fragmentation. For direct compaction we
decided that it's better to risk permanent fragmentation than a
premature OOM, but for kcompactd there doesn't seem to be such
compelling reason.

> Thanks
> Yisheng Xie
> 
>>> Signed-off-by: Yisheng Xie <xieyisheng1@...wei.com>
>>> ---
>>>  mm/compaction.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/compaction.c b/mm/compaction.c
>>> index 0fdfde0..4bf2a5d 100644
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -991,9 +991,6 @@ static bool too_many_isolated(struct zone *zone)
>>>  static bool suitable_migration_target(struct compact_control *cc,
>>>  							struct page *page)
>>>  {
>>> -	if (cc->ignore_block_suitable)
>>> -		return true;
>>> -
>>>  	/* If the page is a large free page, then disallow migration */
>>>  	if (PageBuddy(page)) {
>>>  		/*
>>> @@ -1005,6 +1002,9 @@ static bool suitable_migration_target(struct compact_control *cc,
>>>  			return false;
>>>  	}
>>>  
>>> +	if (cc->ignore_block_suitable)
>>> +		return true;
>>> +
>>>  	/* If the block is MIGRATE_MOVABLE or MIGRATE_CMA, allow migration */
>>>  	if (migrate_async_suitable(get_pageblock_migratetype(page)))
>>>  		return true;
>>>
>>
>>
>> .
>>
>