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]

Date:	Thu, 23 Oct 2014 00:40:57 +0000
From:	朱辉 <zhuhui@...omi.com>
To:	Peter Hurley <peter@...leysoftware.com>,
	Laura Abbott <lauraa@...eaurora.org>,
	"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"riel@...hat.com" <riel@...hat.com>,
	"mgorman@...e.de" <mgorman@...e.de>,
	"hughd@...gle.com" <hughd@...gle.com>,
	"akinobu.mita@...il.com" <akinobu.mita@...il.com>
CC:	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"pavel@....cz" <pavel@....cz>,
	"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>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"nasa4836@...il.com" <nasa4836@...il.com>,
	"ddstreet@...e.org" <ddstreet@...e.org>,
	"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>,
	"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>,
	"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/22/14 20:02, Peter Hurley wrote:
> On 10/16/2014 04:55 AM, 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. 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.
>
> What impact does this series have on x86 platforms now that CMA is the
> backup allocator for all iommu dma allocations?

They will not affect driver CMA memory allocation.

Thanks,
Hui

>
> Regards,
> Peter Hurley
>