On 1/5/2024 4:05 PM, Roman Gushchin wrote: > I'm not sure there is a "one size fits all" solution here. agree - that's why we are thinking a configurable cma utilization would be useful. > 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 Could you please elaborate on this - how would we use the per-cma flags when allocating pages? > 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. Stepping back, we are trying to solve for a situation where system: - has lot of movable allocs in zone normal - has lot of idle memory in CMA region - but is low on memory for unmovable allocs, leading to oom-kills On devices where cma region is mostly idle, allocating movable pages from the cma region would have lesser overhead? IIUC, this redesign for smarter migration would be in addition to or in parallel to the CMA utilization right? Thanks, Sukadev > > Thanks!
