On Fri, Jan 05, 2024 at 03:46:55PM -0800, Sukadev Bhattiprolu wrote: > > On 2/1/2023 3:47 PM, Minchan Kim wrote: > > > > I like this patch for different reason but for the specific problem you > > mentioned, How about making reclaimer/compaction aware of the problem: > > > > IOW, when the GFP_KERNEL/DMA allocation happens but not enough memory > > in the zones, let's migrates movable pages in those zones into CMA > > area/movable zone if they are plenty of free memory. > > Hi Minchan, > > Coming back to this thread after a while. > > If the CMA region is usually free, allocating pages first in the non-CMA > region and then moving them into the CMA region would be extra work since > it would happen most of the time. In such cases, wouldn't it be better to > allocate from the CMA region itself? I'm not sure there is a "one size fits all" solution here. There are two distinctive cases: 1) A relatively small cma area used for a specific purpose. This is how cma was used until recently. And it was barely used by the kernel for non-cma allocations. 2) A relatively large cma area which is used to allocate gigantic hugepages and as an anti-fragmentation mechanism in general (basically as a movable zone). In this case it might be preferable to use cma for movable allocations, because the space for non-movable allocations might be limited. I see two options here: 1) introduce per-cma area flags which will define the usage policy 2) redesign the page allocator to better take care of fragmentation at 1Gb scale The latter is obviously not a small endeavour. The fundamentally missing piece is a notion of an anti-fragmentation cost. E.g. how much work does it makes sense to put into page migration before "polluting" a new large block of memory with an unmovable folio. Thanks!
