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
| ||
|
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 >
Powered by blists - more mailing lists