Re: [LSF/MM/BPF TOPIC] Guaranteed CMA

[Suren Baghdasaryan <surenb@google.com>]

On Tue, Feb 4, 2025 at 1:07 AM Vlastimil Babka <vbabka@suse.cz> 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@kernel.org>, Minchan Kim <minchan@kernel.org>
> > CMA authors: Marek Szyprowski <m.szyprowski@samsung.com>, Aneesh Kumar
> > K.V <aneesh.kumar@kernel.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
> > Michal Nazarewicz <mina86@mina86.com>
> > 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@gmail.com/
>