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@xxxxxxxxxxxxxx/ . 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
