From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5C2FC02194 for ; Tue, 4 Feb 2025 11:23:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2507F6B0089; Tue, 4 Feb 2025 06:23:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2023B6B008A; Tue, 4 Feb 2025 06:23:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F091280001; Tue, 4 Feb 2025 06:23:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E0AEB6B0089 for ; Tue, 4 Feb 2025 06:23:28 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 697421C6C87 for ; Tue, 4 Feb 2025 11:23:28 +0000 (UTC) X-FDA: 83082026496.22.C49A3F5 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 612AC2000F for ; Tue, 4 Feb 2025 11:23:26 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738668206; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AyLQoFZUVfyj+uNsSfWUVTTg5r/RG/SM+ppLw1go7x4=; b=GAcAu4xaHabqghojLYw5UMo6KPquk8i3DCwkGLsssELHOsGfOEQhSn2SVtdUgOUILlbAjv 0hiVYuQPyXqLo2FKNOFSpqlKkr9vSjGsHMFh+x5aw6x71RzfZW/4M6eP8P6HPc0AGjEuue 2hubkFor0LzvlgwgQSy4vi/u4mziaa8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738668206; a=rsa-sha256; cv=none; b=5b09j7xZ6KxpF1CVDHklwSbZELtPqnnorIupE+T0ccxDfzR7TVGETmY+MpfXCVNV/vtSpV Gt3SJGtMschLsnhRYEGFpQ0QLeFDIG19TIMNy/mvGaGOwjmEEFGKl+Aw/XXucUV5wkKuys KibN/V+DHeLZ7zSYsaDlGAXJ6ahU9+E= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6DAAB11FB; Tue, 4 Feb 2025 03:23:49 -0800 (PST) Received: from raptor (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 026E53F5A1; Tue, 4 Feb 2025 03:23:22 -0800 (PST) Date: Tue, 4 Feb 2025 11:23:20 +0000 From: Alexandru Elisei To: David Hildenbrand Cc: Suren Baghdasaryan , lsf-pc@lists.linux-foundation.org, SeongJae Park , Minchan Kim , m.szyprowski@samsung.com, aneesh.kumar@kernel.org, Joonsoo Kim , mina86@mina86.com, Matthew Wilcox , Vlastimil Babka , Lorenzo Stoakes , "Liam R. Howlett" , Michal Hocko , linux-mm , android-kernel-team Subject: Re: [LSF/MM/BPF TOPIC] Guaranteed CMA Message-ID: References: <7944006e-8209-4074-85da-14f5545cd8b6@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7944006e-8209-4074-85da-14f5545cd8b6@redhat.com> X-Stat-Signature: y8r8cnrdptap58qhnzt891fsz9fpg6uo X-Rspam-User: X-Rspamd-Queue-Id: 612AC2000F X-Rspamd-Server: rspam03 X-HE-Tag: 1738668206-710260 X-HE-Meta: U2FsdGVkX1/atq+FZtBinswMhC6MskXDxOkLa9b1rNvNP6i6eCnzCMhx5DBTp5QK+yE/WM6gyrpYgpHE7ctPt4+LmmTaDG2t7/w+mw0k1To4MVODxic0mWyX887Zd9+yxYcJcIxbEZK+9clYY3i7IxDNX7NCb6Em2VoMf0ZezEjDvC3pKJWQjDuGXmLlOy3yVBMWG4QWFY+ysLmndJG1yHS/qn/pWy8ewyTq8lNtnGnz9ElQwbm1ebFKH1Ou5qtvyL6VkGtAb+xv5GeTx8apiKuRfSnfnBey8KrRPcfQpD1ZEM8qIo1lvw7CxKJ67GBdxQjD4hMPsI3WACYdELnq9U3eUvOAr01hfWNbvxu7q1qIFqwNB5r5xrAcEECBtGgsh0PasS/0B4hYPlKJ6UgarjflhTPcIEs1DHTUtYDvxGHLdwv5qENCEM9ZulWsiFnPDlJW1NYMHXNS3g+R5s4F2jBBvOPTf0wbEUd+jCL8a02OYtUe4uAXYUXTm4UV6CHIvEslIOrvQ8iinIuXmZauGdxatSInQhHSzx+Y35EEfLxQWuiGRGcfI03UVCnqADvpVKqFqTgrQPK39+VPcAY4vhVJ22dxij6BPXp76Js1uHgcZvmkgfmEGorps99se7HGtRTHOXDFH/JhiEcLy1px8LNuEAaalXd4v5+4DPdhZeOgNircTQoklWJ+jkpcNefF41oGuslopmZ8ZKQJ9xeZrLkPT79JAVPQD4DcRTxLIKxwQQEMYZB+32PwIHMCXpwxuiajZevEYeW4KOxcwx6rZlk7gIUEA5xeFQHC+aCr5rn3F90K3FosavPnjYGKIbjTmM78kaqTBteMUk6UM8zOk3Sm2lxn+VPNfYOdVv31nXzbbS/xJ8SgJKW73+ApJ7ZmKy4cWjdeqMv/AKOMrk9qtuag2DPGL9FGpI6LTuuikq/PJ45kgxKhL5+UGv5qyo3o36Vt2KXHZO563zJF2p2 L4693e5c TNZ80aVxH/J/XlyUYgiIxJ9JV0CZUd3acK6P4MoPetId/dSfmibADUjxDQCdaYZYhw8r4OPcv7PjV1nw0dKqoSnGYOcnQl+bJuz4MKU1FdgY4eVyEe9XCPUWvLKgJQahOV/O2oR4Btz4JFnGSF1Zdb57JiOu6TQKIvezoFRRgJCC9wuZ2gf3qnvX7EeMn8/9uh8+QioeEMAX51AZzG06x00V1LOIMMuQ4Rt0CyME3iMCxE0Q4dIyOe0/7X3vW9UhVwz9bJ4qgpEk9ass= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000139, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, On Tue, Feb 04, 2025 at 09:18:20AM +0100, David Hildenbrand wrote: > 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. If I remember correctly, one of the issues with the MTE project that might be relevant to GCMA, was that userspace, once it gets a hold of a page, it can pin it for a very long time without specifying FOLL_LONGTERM. If I remember things correctly, there were two examples given for this; there might be more, or they might have been eliminated since then: * The page is used as a buffer for accesses to a file opened with O_DIRECT. * 'vmsplice() can pin pages forever and doesn't use FOLL_LONGTERM yet' - that's a direct quote from David [1]. Depending on your usecases, failing the allocation might be acceptable, but for MTE that wasn't the case. Hope some of this is useful. [1] https://lore.kernel.org/linux-arm-kernel/4e7a4054-092c-4e34-ae00-0105d7c9343c@redhat.com/ Thanks, Alex > > 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@arm.com/ > > -- > Cheers, > > David / dhildenb >