From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Feng Tang <feng.tang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
Laura Abbott <lauraa@codeaurora.org>,
Minchan Kim <minchan@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Michal Nazarewicz <mina86@mina86.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Vlastimil Babka <vbabka@suse.cz>,
Rui Teng <rui.teng@linux.vnet.ibm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/6] Introduce ZONE_CMA
Date: Fri, 27 May 2016 15:42:18 +0900 [thread overview]
Message-ID: <20160527064218.GA14858@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <20160527062527.GA32297@shbuild888>
On Fri, May 27, 2016 at 02:25:27PM +0800, Feng Tang wrote:
> On Fri, May 27, 2016 at 01:28:20PM +0800, Joonsoo Kim wrote:
> > On Thu, May 26, 2016 at 04:04:54PM +0800, Feng Tang wrote:
> > > On Thu, May 26, 2016 at 02:22:22PM +0800, js1304@gmail.com wrote:
> > > > From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > >
>
> > > > FYI, there is another attempt [3] trying to solve this problem in lkml.
> > > > And, as far as I know, Qualcomm also has out-of-tree solution for this
> > > > problem.
> > >
> > > This may be a little off-topic :) Actually, we have used another way in
> > > our products, that we disable the fallback from MIGRATETYE_MOVABLE to
> > > MIGRATETYPE_CMA completely, and only allow free CMA memory to be used
> > > by file page cache (which is easy to be reclaimed by its nature).
> > > We did it by adding a GFP_PAGE_CACHE to every allocation request for
> > > page cache, and the MM will try to pick up an available free CMA page
> > > first, and goes to normal path when fail.
> >
> > Just wonder, why do you allow CMA memory to file page cache rather
> > than anonymous page? I guess that anonymous pages would be more easily
> > migrated/reclaimed than file page cache. In fact, some of our product
> > uses anonymous page adaptation to satisfy similar requirement by
> > introducing GFP_CMA. AFAIK, some of chip vendor also uses "anonymous
> > page first adaptation" to get better success rate.
>
> The biggest problem we faced is to allocate big chunk of CMA memory,
> say 256MB in a whole, or 9 pieces of 20MB buffers, so the speed
> is not the biggest concern, but whether all the cma pages be reclaimed.
Okay. Our product have similar workload.
> With the MOVABLE fallback, there may be many types of bad guys from device
> drivers/kernel or different subsystems, who refuse to return the borrowed
> cma pages, so I took a lazy way by only allowing page cache to use free
> cma pages, and we see good results which could pass most of the test for
> allocating big chunks.
Could you explain more about why file page cache rather than anonymous page?
If there is a reason, I'd like to test it by myself.
> One of the customer used to use a CMA sharing patch from another vendor
> on our Socs, which can't pass these tests and finally took our page cache
> approach.
CMA has too many problems so each vendor uses their own adaptation. I'd
like to solve this code fragmentation by fixing problems on upstream
kernel and this ZONE_CMA is one of that effort. If you can share the
pointer for your adaptation, it would be very helpful to me.
Thanks.
> >
> > > It works fine on our products, though we still see some cases that
> > > some page can't be reclaimed.
> > >
> > > Our product has a special user case of CMA, that sometimes it will
> > > need to use the whole CMA memory (say 256MB on a phone), then all
> >
> > I don't think this usecase is so special. Our product also has similar
> > usecase. And, I already knows one another.
>
> :) I first touch CMA in 2014 and have only worked on Sofia platforms.
>
> >
> > > share out CMA pages need to be reclaimed all at once. Don't know if
> > > this new ZONE_CMA approach could meet this request? (our page cache
> > > solution can't ganrantee to meet this request all the time).
> >
> > This ZONE_CMA approach would be better than before, since CMA memory
> > is not be used for blockdev page cache. Blockdev page cache is one of
> > the frequent failure points in my experience.
>
> Indeed! I also explicitely disabled cma sharing for blkdev FS page cache.
>
> >
> > I'm not sure that ZONE_CMA works better than your GFP_PAGE_CACHE
> > adaptation for your system. In ZONE_CMA, CMA memory is used for file
> > page cache or anonymous pages. If my assumption that anonymous pages
> > are easier to be migrated/reclaimed is correct, ZONE_CMA would work
> > better than your adaptation since there is less file page cache pages
> > in CMA memory.
> >
> > Anyway, it also doesn't guarantee to succeed all the time. There is
> > different kind of problem that prevents CMA allocation success and we
> > need to solve it. I will try it after problems that this patchset try
> > to fix is solved.
>
> ZONE_CMA should be cleaner, while our page cache solution needs to
> adjust some policy for lowmemorykiller and page scan/reclaim code.
>
> Thanks,
> Feng
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-05-27 6:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 6:22 [PATCH v3 0/6] Introduce ZONE_CMA js1304
2016-05-26 6:22 ` [PATCH v3 1/6] mm/page_alloc: recalculate some of zone threshold when on/offline memory js1304
2016-06-24 13:20 ` Vlastimil Babka
2016-06-28 8:12 ` Joonsoo Kim
2016-05-26 6:22 ` [PATCH v3 2/6] mm/cma: introduce new zone, ZONE_CMA js1304
2016-05-26 6:22 ` [PATCH v3 3/6] mm/cma: populate ZONE_CMA js1304
2016-06-22 9:23 ` Chen Feng
2016-06-23 2:52 ` Joonsoo Kim
2016-06-28 11:23 ` Chen Feng
2016-06-29 8:00 ` Joonsoo Kim
2016-06-27 8:24 ` Vlastimil Babka
2016-06-28 8:31 ` Joonsoo Kim
2016-05-26 6:22 ` [PATCH v3 4/6] mm/cma: remove ALLOC_CMA js1304
2016-06-27 9:30 ` Vlastimil Babka
2016-06-28 8:16 ` Joonsoo Kim
2016-05-26 6:22 ` [PATCH v3 5/6] mm/cma: remove MIGRATE_CMA js1304
2016-05-27 1:42 ` Chen Feng
2016-05-27 5:32 ` Joonsoo Kim
2016-06-27 9:46 ` Vlastimil Babka
2016-06-28 8:17 ` Joonsoo Kim
2016-05-26 6:22 ` [PATCH v3 6/6] mm/cma: remove per zone CMA stat js1304
2016-06-27 9:54 ` Vlastimil Babka
2016-05-26 8:04 ` [PATCH v3 0/6] Introduce ZONE_CMA Feng Tang
2016-05-27 5:28 ` Joonsoo Kim
2016-05-27 6:25 ` Feng Tang
2016-05-27 6:42 ` Joonsoo Kim [this message]
2016-05-27 7:27 ` Feng Tang
2016-05-30 5:45 ` Joonsoo Kim
2016-06-17 7:38 ` Chen Feng
2016-06-20 6:48 ` Joonsoo Kim
2016-06-21 2:08 ` Chen Feng
2016-06-21 6:56 ` Joonsoo Kim
2016-06-27 11:25 ` Balbir Singh
2016-06-29 7:57 ` 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=20160527064218.GA14858@js1304-P5Q-DELUXE \
--to=iamjoonsoo.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=feng.tang@intel.com \
--cc=hannes@cmpxchg.org \
--cc=lauraa@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@techsingularity.net \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=rui.teng@linux.vnet.ibm.com \
--cc=vbabka@suse.cz \
/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).