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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux