linux-kernel - Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation

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: <cf4a9f99f7b24b4fb688cb3bcccefb0e@cnbox4.mioffice.cn>
Date:	Fri, 17 Oct 2014 07:44:26 +0000
From:	朱辉 <zhuhui@...omi.com>
To:	Laura Abbott <lauraa@...eaurora.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"pavel@....cz" <pavel@....cz>,
	"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"mina86@...a86.com" <mina86@...a86.com>,
	"aneesh.kumar@...ux.vnet.ibm.com" <aneesh.kumar@...ux.vnet.ibm.com>,
	"iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"riel@...hat.com" <riel@...hat.com>,
	"mgorman@...e.de" <mgorman@...e.de>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"nasa4836@...il.com" <nasa4836@...il.com>,
	"ddstreet@...e.org" <ddstreet@...e.org>,
	"hughd@...gle.com" <hughd@...gle.com>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"rientjes@...gle.com" <rientjes@...gle.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"atomlin@...hat.com" <atomlin@...hat.com>,
	"raistlin@...ux.it" <raistlin@...ux.it>,
	"axboe@...com" <axboe@...com>,
	"paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"n-horiguchi@...jp.nec.com" <n-horiguchi@...jp.nec.com>,
	"k.khlebnikov@...sung.com" <k.khlebnikov@...sung.com>,
	"msalter@...hat.com" <msalter@...hat.com>,
	"deller@....de" <deller@....de>,
	"tangchen@...fujitsu.com" <tangchen@...fujitsu.com>,
	"ben@...adent.org.uk" <ben@...adent.org.uk>,
	"akinobu.mita@...il.com" <akinobu.mita@...il.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>,
	"sasha.levin@...cle.com" <sasha.levin@...cle.com>,
	"vdavydov@...allels.com" <vdavydov@...allels.com>,
	"suleiman@...gle.com" <suleiman@...gle.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive
 about allocation



On 10/16/14 16:56, Laura Abbott wrote:
> On 10/15/2014 8:35 PM, Hui Zhu wrote:
>> In fallbacks of page_alloc.c, MIGRATE_CMA is the fallback of
>> MIGRATE_MOVABLE.
>> MIGRATE_MOVABLE will use MIGRATE_CMA when it doesn't have a page in
>> order that Linux kernel want.
>>
>> If a system that has a lot of user space program is running, for
>> instance, an Android board, most of memory is in MIGRATE_MOVABLE and
>> allocated.  Before function __rmqueue_fallback get memory from
>> MIGRATE_CMA, the oom_killer will kill a task to release memory when
>> kernel want get MIGRATE_UNMOVABLE memory because fallbacks of
>> MIGRATE_UNMOVABLE are MIGRATE_RECLAIMABLE and MIGRATE_MOVABLE.
>> This status is odd.  The MIGRATE_CMA has a lot free memory but Linux
>> kernel kill some tasks to release memory.
>>
>> This patch series adds a new function CMA_AGGRESSIVE to make CMA memory
>> be more aggressive about allocation.
>> If function CMA_AGGRESSIVE is available, when Linux kernel call function
>> __rmqueue try to get pages from MIGRATE_MOVABLE and conditions allow,
>> MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first.  If MIGRATE_CMA
>> doesn't have enough pages for allocation, go back to allocate memory from
>> MIGRATE_MOVABLE.
>> Then the memory of MIGRATE_MOVABLE can be kept for MIGRATE_UNMOVABLE and
>> MIGRATE_RECLAIMABLE which doesn't have fallback MIGRATE_CMA.
>>
>
> It's good to see another proposal to fix CMA utilization.

Thanks Laura.

Do you have
> any data about the success rate of CMA contiguous allocation after
> this patch series?   I played around with a similar approach of using
> CMA for MIGRATE_MOVABLE allocations and found that although utilization
> did increase, contiguous allocations failed at a higher rate and were
> much slower. I see what this series is trying to do with avoiding
> allocation from CMA pages when a contiguous allocation is progress.
> My concern is that there would still be problems with contiguous
> allocation after all the MIGRATE_MOVABLE fallback has happened.

I did some test with the cma_alloc_counter and cma-aggressive-shrink in 
a android board that has 1g memory.  Run some apps to make free CMA 
close to the value of cma_aggressive_free_min(500 pages).  A driver 
Begin to request CMA more than 10 times. Each time, it will request more 
than 3000 pages.

I don't have established number for that because it is really hard to 
get a fail.  I think the success rate is over 95% at least.

And I think maybe the isolate fail has relation with page alloc and free 
code.  Maybe let zone->lock protect more code can handle this issue.

Thanks,
Hui

>
> Thanks,
> Laura
>