On 2/2/25 01:19, Suren Baghdasaryan wrote: > 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 By reference you men a (long-term) pin? Otherwise "no reference" would mean no way to map the pages or read() from them etc. Also there might be speculative references by physical scanners... > 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/