From: Vlastimil Babka <vbabka@suse.cz>
To: Laura Abbott <lauraa@codeaurora.org>, Hui Zhu <zhuhui@xiaomi.com>,
rjw@rjwysocki.net, len.brown@intel.com, pavel@ucw.cz,
m.szyprowski@samsung.com, akpm@linux-foundation.org,
mina86@mina86.com, aneesh.kumar@linux.vnet.ibm.com,
iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, riel@redhat.com,
mgorman@suse.de, minchan@kernel.org, nasa4836@gmail.com,
ddstreet@ieee.org, hughd@google.com, mingo@kernel.org,
rientjes@google.com, peterz@infradead.org, keescook@chromium.org,
atomlin@redhat.com, raistlin@linux.it, axboe@fb.com,
paulmck@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com,
n-horiguchi@ah.jp.nec.com, k.khlebnikov@samsung.com,
msalter@redhat.com, deller@gmx.de, tangchen@cn.fujitsu.com,
ben@decadent.org.uk, akinobu.mita@gmail.com,
sasha.levin@oracle.com, vdavydov@parallels.com,
suleiman@google.com
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation
Date: Wed, 29 Oct 2014 15:43:33 +0100 [thread overview]
Message-ID: <5450FD15.4000708@suse.cz> (raw)
In-Reply-To: <543F8812.2020002@codeaurora.org>
On 10/16/2014 10:55 AM, Laura Abbott wrote:
> On 10/15/2014 8:35 PM, Hui Zhu wrote:
>
> 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.
Hi,
did anyone try/suggest the following idea?
- keep CMA as fallback to MOVABLE as is is now, i.e. non-agressive
- when UNMOVABLE (RECLAIMABLE also?) allocation fails and CMA pageblocks
have space, don't OOM immediately, but first try to migrate some MOVABLE
pages to CMA pageblocks, to make space for the UNMOVABLE allocation in
non-CMA pageblocks
- this should keep CMA pageblocks free as long as possible and useful
for CMA allocations, but without restricting the non-MOVABLE allocations
even though there is free memory (but in CMA pageblocks)
- the fact that a MOVABLE page could be successfully migrated to CMA
pageblock, means it was not pinned or otherwise non-migratable, so
there's a good chance it can be migrated back again if CMA pageblocks
need to be used by CMA allocation
- it's more complex, but I guess we have most of the necessary
infrastructure in compaction already :)
Thoughts?
Vlastimil
> Thanks,
> Laura
>
next prev parent reply other threads:[~2014-10-29 14:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 3:35 [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Hui Zhu
2014-10-16 3:35 ` [PATCH 1/4] (CMA_AGGRESSIVE) Add CMA_AGGRESSIVE to Kconfig Hui Zhu
2014-10-18 22:15 ` Pavel Machek
[not found] ` <201410220126.s9M1Qita026502@spam.xiaomi.com>
2014-10-22 5:44 ` 朱辉
2014-10-16 3:35 ` [PATCH 2/4] (CMA_AGGRESSIVE) Add argument hibernation to function shrink_all_memory Hui Zhu
2014-10-16 8:45 ` Rafael J. Wysocki
2014-10-17 6:18 ` 朱辉
2014-10-17 9:28 ` [PATCH v2 2/4] (CMA_AGGRESSIVE) Add new function shrink_all_memory_for_cma Hui Zhu
2014-10-18 4:50 ` PINTU KUMAR
2014-10-16 3:35 ` [PATCH 3/4] (CMA_AGGRESSIVE) Update reserve custom contiguous area code Hui Zhu
2014-10-17 9:30 ` [PATCH v2 " Hui Zhu
2014-10-16 3:35 ` [PATCH 4/4] (CMA_AGGRESSIVE) Update page alloc function Hui Zhu
2014-10-24 5:28 ` Joonsoo Kim
2014-11-28 3:45 ` Hui Zhu
2014-10-16 5:13 ` [PATCH 0/4] (CMA_AGGRESSIVE) Make CMA memory be more aggressive about allocation Weijie Yang
2014-10-16 8:55 ` Laura Abbott
2014-10-17 7:44 ` 朱辉
2014-10-22 12:01 ` Peter Hurley
2014-10-23 0:40 ` 朱辉
2014-10-29 14:43 ` Vlastimil Babka [this message]
2014-11-03 8:46 ` Hui Zhu
2014-11-04 7:53 ` Minchan Kim
2014-11-04 8:59 ` Hui Zhu
2014-11-04 9:29 ` Vlastimil Babka
2014-11-07 7:06 ` Minchan Kim
2014-10-24 5:25 ` Joonsoo Kim
2014-11-03 7:28 ` Hui Zhu
2014-11-03 8:05 ` Joonsoo Kim
2014-11-04 2:31 ` Joonsoo Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5450FD15.4000708@suse.cz \
--to=vbabka@suse.cz \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=atomlin@redhat.com \
--cc=axboe@fb.com \
--cc=ben@decadent.org.uk \
--cc=ddstreet@ieee.org \
--cc=deller@gmx.de \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=k.khlebnikov@samsung.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=lauraa@codeaurora.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=mingo@kernel.org \
--cc=msalter@redhat.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nasa4836@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=raistlin@linux.it \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=rjw@rjwysocki.net \
--cc=sasha.levin@oracle.com \
--cc=suleiman@google.com \
--cc=tangchen@cn.fujitsu.com \
--cc=vdavydov@parallels.com \
--cc=zhuhui@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).