On Tue, Feb 4, 2025 at 1:07 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > 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... By that I mean that the cleancache memory is not addressable by the kernel, see: https://elixir.bootlin.com/linux/v5.16.20/source/Documentation/vm/cleancache.rst#L19. > > > 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/ >
