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:
quoted
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 :-)
quoted
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/ (local)
.
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.