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 4D340C28B30 for ; Thu, 20 Mar 2025 18:06:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82465280010; Thu, 20 Mar 2025 14:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D351280008; Thu, 20 Mar 2025 14:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3A2280010; Thu, 20 Mar 2025 14:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 48D19280008 for ; Thu, 20 Mar 2025 14:06:36 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5AEF31CC9C7 for ; Thu, 20 Mar 2025 18:06:37 +0000 (UTC) X-FDA: 83242709634.20.2BD57FF Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf28.hostedemail.com (Postfix) with ESMTP id 0C482C0023 for ; Thu, 20 Mar 2025 18:06:34 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="dm/vEnNI"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742493995; a=rsa-sha256; cv=none; b=EkFu0//QhhAE38SmkENOTQVMROibw1hGTznm4WaU1MIE6p5OoUKWGNoxBdL7VMuu9QOPOA wqQZPC3eUpeDkNmA0WEM8Udx7gF3YE+bvvbI94lAo6cxV84pxSyg2IOoOAD8v1T1D+/8fx u9IMBRC3QGnTNok6RQKkcrmt/bw0QDU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="dm/vEnNI"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742493995; 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:dkim-signature; bh=hdboRJjtYbBeZa6ex9Z3Fhk0JWATwsKgMjGOnaWVKv4=; b=kxqvP1fpeqmBLLLHmk6bP7PqqABKMSD5VAVB1NjnZcm7VIuOV58OVTd185AMW1+JHWoIB8 5HDl9QBKX9H4Awzmbz2FOLeHNXZKSGlJWbuc55xfjoJEeETmDvqXmtbcqGdxzdyG0Bw8L4 eX7euaNZS43DEX3EZs0dl0wz2Hzc2yA= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-47666573242so54571cf.0 for ; Thu, 20 Mar 2025 11:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742493994; x=1743098794; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hdboRJjtYbBeZa6ex9Z3Fhk0JWATwsKgMjGOnaWVKv4=; b=dm/vEnNIxUm4sCmgMr7pS11rqRmQZwdk83l/re4WLPtD1sxELeP0i53/Nc16w3NWf2 QPSqoRczqB+ghaySCW6VyUa8z69l8XGZt0/9+BIcK4VN2xMiI/8lHnBh9t5/YIikipft wglkjccnng6eDEaOO5AOA6ZT2mXLlB+KBsiW5qjTmPvdlX7G1ifeVMYza5RrmBDmHycB jjHoK+S3oEKVWmBxMBzWNtl2Snl56IkZ50TaRDs89utfbdYiXKvfPCRwz1+ZmSNxvaPI KOdTGAT9G2gisHfcFlSmXA5vpyKaH7PsnD+vt4d4axQNdTA1NsnAkg+IkXk48BhPsizA 2geA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742493994; x=1743098794; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hdboRJjtYbBeZa6ex9Z3Fhk0JWATwsKgMjGOnaWVKv4=; b=Sr3cSgiugAXbBqdnwVb/UuAMR3ZR7w5971Xw917439Nj0NXe7RwYwsNG6e8sC9v0vM 8Hd7A9EZ9aDFVRGr3sbows5T+fIeSQBQFNVVbhmlnfPYprnsaL8pEcDTO53eEBUcfAhW /Afo1VKCXJtzwMlkdlyyIGdJVgTkStEVfVXRu/HcScZxD/5tyxfpQNRzQK7cMjvcohkw i6a98HlVlwLBYYuVyK9Si5DFUYESOtcT/uPMLd+Gzfrk7z01OB38S3kQCX/DE6xp0u9A o4HxOq09DvvtYCM2yRJqS2MMoigYHK6lO1ZXMJXDTBbOhH0z+Teuge/+4Ja8NQPJS2dX drGQ== X-Forwarded-Encrypted: i=1; AJvYcCUCmAy/u3UAR5XPjmibFMroqd0kOb1HaeKzt/C37aCNDcdtG2o79nhKTFoSqgF7QvhA7dztBd2zjQ==@kvack.org X-Gm-Message-State: AOJu0Yyd2UcD8WSSTrQF7Kp+YEHEiESXvLeyATKxAUHkFASWp1yivjMI BUVInVpbB7mE1bC2axSvxlFJZFxsmCqEhcnpv7M0ofTuv3aQMJ66m9wHpSaoS9KKG+RNfyZEabs ngwCyvp2D8jzlYL7Ip5w45+W1f+BoDaI8LYZ6 X-Gm-Gg: ASbGnctkJkr8n4/BK5GmD4pMkZo8Fu5KUrVKg2K5waTbuWlRi6oZGvUEVYdU27xvhda riH2amX/ma6njYluJgHya/sSMcTN7V7os/nupq00CYp0OXeODXhFVdHJ/gOvFkohJsmpTkWv3dW LNnGmYLqzrdH43T376QEhkhe4BxWkjoZqtxFUruyUbIhjKILyytwEZs2a+ X-Google-Smtp-Source: AGHT+IEhM7OK/QPNMShwcm/XYU0yK5+UIoLIg6HqhReioyrEJcjicWZW2OQS6UJ9BPABWsbDs47+tJ3tw1zfZegltlQ= X-Received: by 2002:a05:622a:5c10:b0:472:7e8:a788 with SMTP id d75a77b69052e-4771e0b57bdmr248281cf.12.1742493993381; Thu, 20 Mar 2025 11:06:33 -0700 (PDT) MIME-Version: 1.0 References: <7944006e-8209-4074-85da-14f5545cd8b6@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 20 Mar 2025 11:06:22 -0700 X-Gm-Features: AQ5f1JrDXjmgXZMZLGn8DIrapHVPgwl0ACTYC3WRzB667mVUhu-EQq55obPROsA Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Guaranteed CMA To: Alexandru Elisei Cc: David Hildenbrand , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 0C482C0023 X-Stat-Signature: o6814a3we1bwkr6jd1a6rezenx67exu4 X-Rspamd-Server: rspam06 X-HE-Tag: 1742493994-63123 X-HE-Meta: U2FsdGVkX18QuxHjx1tjKcspCnrG2oDT5jiufBrKPjJG0t/pKc7CG/3qswwEvSvgrArL5h42lSuIc6WjjE/HDSQDt3XHDXcYEqjeNL11StYBaLaKjlwJcLUrPnRWkhteye8bXuMoIxvYqwJ5ENNDrGDQZ7WeZH8qoecozpPFbwUTnGqzCCSkUTV3gMSPd4KH8bVTXc+sQGPKhEaG4TDj41Uu537UFUv94nFOw99s5taB6l1QLaNUAq1x8f4P7C3Yn4YCE7/rfARVeGP9OK0Rn4acwWT3IgsM600ipNE5ESxf3Vc1tM6NefJuqeCWSHmMjvobpkWekTeyjMD/cVCjVcFHujyXvSFtjFrzG1rrofA0+6edaVwxmIpTps4p7FMsHy9TzODFou6sY3A4GPkULfRumMiTAdgLSvjHsVatsXaYWaVyqwpaGHTO9CKf0f+7IagXaedQDarXOE1JXLA0J8DwJgqho4t0RyEewcWFx4QURuJXaF5IWrmyzEKha6IAb8kw2fqu1ab+DxgGTzOX3rlPVfPFL89jgbbksr67e7pldzJl5B6ZozY1cLBdUUFECK95iYGobZw6KvhCcEpCxcdlktZR0r0XvPQUDslJ7YY1bqiPenDM2KGZbzzHDc0fVzmoSJRlwOkYck6ASo36N9DwyiwUJ2qZ04qeMH9xT/icaFfdo/UuKu2YRt8x/1XIAg8iEb9+3VLJgTRCErzhNL6Xls74Zp551zA9CMbZe5C8XDlJe2hMWyCO8GZtnIFs4BUBBpRxVf8JMkoQEZ/mhDwnUVMOg5+0vemseSmQ1etnS/R/InwP4fYiYhwfP8rBbWX7NfVJg53Me8u3JUxGiyj3LW/BLSIsSHDokxlnTU0ysZuoh1xPxXTRQb/HoAdUSpu/LnvugG3Usgo1dl6tgdoGAoyooKr7tdaByeLFUTp0kjtKSiKRdmwfKhKzJVQq12IQruoqhD8Q1nPlci6 uwwlopr+ X3UbtbgiLmjmUh6wIqkoIq3m4EV2t6e8drZvg9pyZpcGcNCediTthY57pWbp0muty8o3Me6HqiTUFOZj+CCPJYxFA3XZiDv/4U0vxphe68fqC/NiVXXwF1B1MQTMf76tm+kyCwGUB41xEJYXqizLqYnXGI17/PoXwqWhDmByam20g3G7b4/QrW1S0iDg+5hEl5V/eCaTXwgN3tVQV7ZBt2ew+4UzrzsaAoXrVu9YviMxGelH0njQ6q1J8yAxGXq7pWQAS5w2T6CFFgN6WtwmrWGNt3oe5pf+c5VoUk2Te/gqb8qqOAow6JGnHOByomdzmPu8v2QPdhgscmfU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.005074, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 4, 2025 at 8:33=E2=80=AFAM Suren Baghdasaryan wrote: > > On Tue, Feb 4, 2025 at 3:23=E2=80=AFAM Alexandru Elisei > wrote: > > > > 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=E2=80=99s 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 als= o > > > > fail if page migration is not possible. > > > > > > > > GCMA (Guaranteed CMA) is a mechanism previously proposed in [1] whi= ch > > > > 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=E2=80=99t take a reference to pages fro= m the > > > > cleancache, therefore can=E2=80=99t prevent GCMA from quickly dropp= ing them > > > > when required. This guarantees GCMA low allocation latency and > > > > improves allocation success rate. > > > > > > > > We would like to standardize GCMA implementation and upstream it si= nce > > > > 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=E2=80=99t know at the time about this use case) might complica= te > > > > upstreaming. > > > > > > we discussed another possible user last year: using MTE tag storage m= emory > > > 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 ar= ea does > > > not use MTE tagging, we can reuse the MTE tag storage ("almost ordina= ry 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 mi= ght 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-01= 05d7c9343c@redhat.com/ > > Thanks for the references! I'll read through these discussions to see > how much useful information for GCMA I can extract. I wanted to get an RFC code ahead of LSF/MM and just finished putting it together. Sorry for the last minute posting. You can find it here: https://lore.kernel.org/all/20250320173931.1583800-1-surenb@google.com/ Thanks, Suren. > > > > > 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 so= mething > > > like swap/zswap: where the pages cannot get pinned / turned unmovable= . > > > > > > [1] https://lore.kernel.org/linux-mm/ZOc0fehF02MohuWr@arm.com/ > > > > > > -- > > > Cheers, > > > > > > David / dhildenb > > >