Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP

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
Date: Fri, 21 Aug 2020 16:38:13 +0900	[thread overview]
Message-ID: <20200821073813.GA190335@KEI> (raw)
In-Reply-To: <20200819132204.2rki3xsczdy2cpsk@DESKTOP-E1NTVVP.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

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.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]