Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 21 Aug 2020 16:38:13 +0900
From:   Cho KyongHo <pullip.cho@samsung.com>
To:     Brian Starkey <brian.starkey@arm.com>
Cc:     Hyesoo Yu <hyesoo.yu@samsung.com>, sumit.semwal@linaro.org,
        minchan@kernel.org, akpm@linux-foundation.org,
        iamjoonsoo.kim@lge.com, joaodias@google.com, linux-mm@kvack.org,
        surenb@google.com, vbabka@suse.cz, afd@ti.com,
        benjamin.gaignard@linaro.org, lmark@codeaurora.org,
        labbott@redhat.com, john.stultz@linaro.org,
        christian.koenig@amd.com, linux-media@vger.kernel.org,
        dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
        linux-kernel@vger.kernel.org, robh+dt@kernel.org,
        devicetree@vger.kernel.org, nd@arm.com
Subject: Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
Message-ID: <20200821073813.GA190335@KEI>
MIME-Version: 1.0
In-Reply-To: <20200819132204.2rki3xsczdy2cpsk@DESKTOP-E1NTVVP.localdomain>
User-Agent: Mutt/1.5.24 (2015-08-30)
Content-Type: multipart/mixed;
        boundary="----lWUYs60uNheWdrlwd5Sxb-jVEnyT8vPvqGqUNsoxLEsY2Otg=_4f1bd_"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <CGME20200818074547epcas2p21e0c2442873d03800c7bc2c3e76405d6@epcas2p2.samsung.com>
        <20200818080415.7531-1-hyesoo.yu@samsung.com>
        <20200818105557.svky5c7gdvk6khzu@DESKTOP-E1NTVVP.localdomain>
        <20200819034626.GB70898@KEI>
        <20200819132204.2rki3xsczdy2cpsk@DESKTOP-E1NTVVP.localdomain>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

------lWUYs60uNheWdrlwd5Sxb-jVEnyT8vPvqGqUNsoxLEsY2Otg=_4f1bd_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline

Hi Brain,

On Wed, Aug 19, 2020 at 02:22:04PM +0100, Brian Starkey wrote:
> Hi KyongHo,
> 
> On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> > I have seriously considered CPA in our product but we developed our own
> > because of the pool in CPA.
> 
> Oh good, I'm glad you considered it :-)
> 
> > The high-order pages are required by some specific users like Netflix
> > app. Moreover required number of bytes are dramatically increasing
> > because of high resolution videos and displays in these days.
> > 
> > Gathering lots of free high-order pages in the background during
> > run-time means reserving that amount of pages from the entier available
> > system memory. Moreover the gathered pages are soon reclaimed whenever
> > the system is sufferring from memory pressure (i.e. camera recording,
> > heavy games).
> 
> Aren't these two things in contradiction? If they're easily reclaimed
> then they aren't "reserved" in any detrimental way. And if you don't
> want them to be reclaimed, then you need them to be reserved...
> 
> The approach you have here assigns the chunk of memory as a reserved
> CMA region which the kernel is going to try not to use too - similar
> to the CPA pool.
> 
> I suppose it's a balance depending on how much you're willing to wait
> for migration on the allocation path. CPA has the potential to get you
> faster allocations, but the downside is you need to make it a little
> more "greedy".
> 
I understand why you think it as contradiction. But I don't think so.
Kernel page allocator now prefers free pages in CMA when allocating
movable pages by commit
https://lore.kernel.org/linux-mm/CAAmzW4P6+3O_RLvgy_QOKD4iXw+Hk3HE7Toc4Ky7kvQbCozCeA@mail.gmail.com/
.

We are trying to reduce unused pages to improve performance. So, unused
pages in a pool should be easily reclaimed. That is why we does not
secure free pages in a special pool for a specific usecase. Instead we
have tried to reduce performance bottle-necks in page migration to
allocate large amount memory when the memory is needed.

------lWUYs60uNheWdrlwd5Sxb-jVEnyT8vPvqGqUNsoxLEsY2Otg=_4f1bd_
Content-Type: text/plain; charset="utf-8"


------lWUYs60uNheWdrlwd5Sxb-jVEnyT8vPvqGqUNsoxLEsY2Otg=_4f1bd_--