On 02.02.25 01:19, Suren Baghdasaryan wrote:
Hi,
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.
we discussed another possible user last year: using MTE tag storage memory while the storage is not getting used to store MTE tags [1].
As long as the "ordinary RAM" that maps to a given MTE tag storage area does not use MTE tagging, we can reuse the MTE tag storage ("almost ordinary RAM, just that it doesn't support MTE itself") for different purposes.
We need a guarantee that that memory can be freed up / migrated once the tag storage gets activated.
We continued that discussion offline, and two users of such memory we discussed would be frontswap, and using it as a memory backend for something like swap/zswap: where the pages cannot get pinned / turned unmovable.
[1] https://lore.kernel.org/linux-mm/ZOc0fehF02MohuWr@xxxxxxx/ -- Cheers, David / dhildenb
