Hi, I would like to discuss the Guaranteed Contiguous Memory Allocator (GCMA) mechanism that is being used by many Android vendors as an out-of-tree feature, collect input on its possible usefulness for others, feasibility to upstream and suggestions for possible better alternatives. Problem statement: Some workloads/hardware require physically contiguous memory and carving out reserved memory areas for such allocations often lead to inefficient usage of those carveouts. CMA was designed to solve this inefficiency by allowing movable memory allocations to use this reserved memory when it’s otherwise unused. When a contiguous memory allocation is requested, CMA finds the requested contiguous area, possibly migrating some of the movable pages out of that area. In latency-sensitive use cases, like face unlock on phones, we need to allocate contiguous memory quickly and page migration in CMA takes enough time to cause user-perceptible lag. Such allocations can also fail if page migration is not possible. GCMA (Guaranteed CMA) is a mechanism previously proposed in [1] which was not upstreamed but got adopted later by many Android vendors as an out-of-tree feature. It is similar to CMA but backing memory is cleancache backend, containing only clean file-backed pages. Most importantly, the kernel can’t take a reference to pages from the cleancache, therefore can’t prevent GCMA from quickly dropping them when required. This guarantees GCMA low allocation latency and improves allocation success rate. We would like to standardize GCMA implementation and upstream it since many Android vendors are asking to include it as a generic feature. Note: removal of cleancache in 5.17 kernel due to no users (sorry, we didn’t know at the time about this use case) might complicate upstreaming. Desired participants: GCMA authors: SeongJae Park <sj@xxxxxxxxxx>, Minchan Kim <minchan@xxxxxxxxxx> CMA authors: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>, Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxx>, Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>, Michal Nazarewicz <mina86@xxxxxxxxxx> The usual suspects (Willy, Vlastimil, Lorenzo, Liam, Michal, David H), other mm folks [1] https://lore.kernel.org/lkml/1424721263-25314-2-git-send-email-sj38.park@xxxxxxxxx/
