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 56384C02193 for ; Tue, 4 Feb 2025 16:33:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBDC76B0092; Tue, 4 Feb 2025 11:33:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D6DAE6B0095; Tue, 4 Feb 2025 11:33:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0E246B0096; Tue, 4 Feb 2025 11:33:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A32BC6B0092 for ; Tue, 4 Feb 2025 11:33:58 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 19BDC80B64 for ; Tue, 4 Feb 2025 16:33:58 +0000 (UTC) X-FDA: 83082808956.16.BC17B76 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf01.hostedemail.com (Postfix) with ESMTP id 3474B4000D for ; Tue, 4 Feb 2025 16:33:55 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Y9q/eSqY"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738686836; a=rsa-sha256; cv=none; b=fdRi2EsXmqGLmvajuXCfik3aZD9OFlnSgmhySTK1rlLIMSQbixuU0jsI9p5MEzhy2xtJPf rMqVFoknepYyV+c6qhWp/NqtsdlvJ01oJVIeLrBZXw168XjflziWdxPokHjTR4JDibZcgM 3CWhmmhEzl6qjNv18mo9QAr3R9ZHdZU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Y9q/eSqY"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.160.180 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=1738686836; 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=yABQBh3Oh04Yk9bww9D04/M6BEeeO4/OpXGQbb4V3jY=; b=MpZRi+1HQKPoCjfPRieQ1znHIO6sFfB1U7MvSrEFwkbNuCHCqAEsk7jxbvmFUCwgoc5EK2 9nPO1nyPVgA9/9mMMPzvJljt7FPscYt37fOzgo0b+3EDxKoymnX6ALVcKXNruerUvZgO4G EVHr+0CvFKC8Aam+L2eQJDnqfJ05LIU= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-467896541e1so311781cf.0 for ; Tue, 04 Feb 2025 08:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738686835; x=1739291635; 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=yABQBh3Oh04Yk9bww9D04/M6BEeeO4/OpXGQbb4V3jY=; b=Y9q/eSqYBetPKSucJPbfdgF9G2Hzo3+FcLKIVs83w7Q/8frR+TroUqMA4CQ74DKsKL boFfl1h7YMJY0YX2jgYHBfTAefeWMpyc0DaytoCYCuBRGbQr+m8N8eOjHpRZcIoXRMFG 9V1s+WNnNTZ6GHLKYCpm7apxTYeKsvoZ0l/xYjJmJXDUFYyUmn4aKz/ACBJsiC4QiecV sN+d6nhZTjiLFAMFxsuQBsPpxTdlNF0G2RRZaiLNevLvUFFqYHvT4Y3VrTzgfOSpIz+J tQGDjWIToTk2YcR60zsMyRdwZiXMIislHXZ4bkjY93SXfq+OxPkDvk8lx4uJzePmtsd7 FVoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738686835; x=1739291635; 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=yABQBh3Oh04Yk9bww9D04/M6BEeeO4/OpXGQbb4V3jY=; b=CxZ4u14RW7K00BFD/hbm3JSdPUR0RqQeEkeqkx/ol/SlGNX6Fw+vfe0czJYrieMLt/ STnxRf8gu8DIsUhC57Gu9dQm+wpFy6Fdmi2+3j+rVqXaUyNcaAVSHaquvsE2bcBvP8Dr zUJWitloXRMmwAHNwPEtkKT7ixZwN8l3eGfnC4mp2wbdAQMTkT5AAhT/VdCp5s/GA1UF QryIEiK4CZ/4RyVVINJTaIuTG6l5eAxa3n2kG9Avn0K/mylOx9Xw7R/ehgmnjnv0odvK aZydMmfz7AC2Gn+H24D16Q5aT2juzc/uTck8J2qOwI0IOps1cjpteInFo1r2dAZju3xL Z6sg== X-Forwarded-Encrypted: i=1; AJvYcCXd+8TkAwnlI9a5x10ndXJyQ1oKmlM2cxj2CFZH9HTwoJ3tulgaYYxdiXyW1z2VP5u35BFpSWoH5Q==@kvack.org X-Gm-Message-State: AOJu0Yyda9vQ1FTaelUoA011HuI0IYaf7TjZr9dxbo6HH9ojOFDkSssI iCycaSf4RESlZi8S5LFc0LyHwpQ4gUf8/W2ouNDKnbIIiFrVkck3osDH0J3VvBZfzcV9WjlYOFo XaBp+H8F/a5OGIH3fOkBRT4u9p1jh3YE77IUZ X-Gm-Gg: ASbGnctQ5htlrws4HgrX0JqHLm3zOaKO0yLWof256EwzHdmBcoIzpRu2sBkQdJ7sMXL 6Kl/Ajwo5yxBDFe7IYaNKSr6/8Umm5tnyxFF1MrThfwNo4t9Fx0jCdo/13kD4nksBAfimp0iOOV mJr1FLJHbHobpyhfoZCEhooycszFA= X-Google-Smtp-Source: AGHT+IG+SqVvv1x6Bxcr4UlyB9eLeMmBBPrLWAmbbjkhBXqwfafZlKSc1MPLlMOf8plELkDmR2Bk3dVa0zP3GEoaJQM= X-Received: by 2002:a05:622a:34f:b0:46c:9f17:12dd with SMTP id d75a77b69052e-4701ab77f50mr3769921cf.19.1738686833577; Tue, 04 Feb 2025 08:33:53 -0800 (PST) MIME-Version: 1.0 References: <7944006e-8209-4074-85da-14f5545cd8b6@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 4 Feb 2025 08:33:42 -0800 X-Gm-Features: AWEUYZkqBeLcqLLTdnptLfjka38RhC-fFUvUz1w07QUgX7QGMvweItVVhqFAvuM 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3474B4000D X-Stat-Signature: 5p1p89ieo46d3jy8a4kzkkkcnnnf9dum X-Rspam-User: X-HE-Tag: 1738686835-924382 X-HE-Meta: U2FsdGVkX19ykEAy722vQwesQw9U49S5HKBgd5A9p6KCfrXZe5Q6qb7UMNcEeHkbfEMWnqAaqU6t3s+RsjvgEKuR1X2ZcrFq3cWGHqaImp6Xo/RV96QBsYP4wK3rmVND1UxXGnn8GzRAWQs4xB62w1uB6qG1ObnPnk4w+2Qizk3u3yS3fQK/2zcw0Zlv5kAL6o8AS9BugXjf4lSTIjxNu/6m2QeT+dfhitLPXh82YqdFJ68WsFMx9szhZQoi8mL2FcwrB3PTvsJz/GGMxYfXANwqwkDwO9HUg0dstT3xnUyYTWZm7lNvj52JThT6TTVY8wS4g6SCF4f26RLKprxS575nqB4rwR4GyWayvtRbAWXLgpuGhpZtxMyJ77VkAUJA1BV7Kftn3pGz9IDCILnq61CRhZgDmMuPRyS6gqRmYGjQoNtgqccH2FBXJ/YUawe0SxRXnOMW20Coug0hGxlqTzbeuEXR3PBPz/jmb4+Ce6lKPczBFd5kYhB45aKwXeswUJlUKCAAHWqRX/UDd6uHtL/gX9FVIYcYvwx6dI0JULsOYlQupyBk+sJf3GexeelcmXn05S3+yGpzgsgM/3mAwGco3b8Qj+RBD81ElqEpEZXygCiz4DF5y8dP0TQbDyosQaOFj9J7HS294xGWn2FRe8p9FgiRo/SI6imrch3RukCigJRaLBjbdMps93O9fQylMEuKP5EL4fSoY3XvcEjqc9PJ5mFHYNdvL/8xqx2NXuRvcvEiWHNCWhn2AnM9/AtrnXf0Uf7+XoW4ItS1e54E3XjJPGE4uCC8RmALtGTufSoTpYH0ec0xOufA8jiqTKa40q67ZIWabjAWAqQMw0S9hie7gEWNHNVZy3wZyyUSZjoi3K28/KUiF8VLf2dhDYgt7muNOy75jtG3Fl1Q58NiC0QUPyHPhw2WeXler37zE86IEYhIkDASlLw93a1l2o5rQhMFeu6sCroQTLM4If4 V0B2/Ump KbILEWJVLExdhjL/AkAbxT5dUOhohsK7gUMVxmJLMSO4qi9Tpz/QiiutjmZRyi+WabVqctawEZN7NR7SaW8OQwiNQj5Pji9fMVILCxQD76JkFCzpse6j4RKyFdQ65xvcbnilxtcgnZL3ltKBYS1k0HWbKnlpmfygqyNZ+DvYH3kob/O0jgjyB3pg+mmJklWS9wvoJTv7os8HUL917KjrkOBDMHzSflzpwbS4u0Xb5pqTUmE5QswT9mux006rq+dL5v9j58DHgouR8DVE/XHyn1drndNtxIWWSpbjlo93YHXOrqbA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.010322, 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 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 u= nused. > > > 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 t= o > > > 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 a= n > > > 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 from = the > > > cleancache, therefore can=E2=80=99t prevent GCMA from quickly droppin= g them > > > when required. This guarantees GCMA low allocation latency and > > > improves allocation success rate. > > > > > > We would like to standardize GCMA implementation and upstream it sinc= e > > > 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 complicate > > > upstreaming. > > > > we discussed another possible user last year: using MTE tag storage mem= ory > > 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 th= e tag > > storage gets activated. > > If I remember correctly, one of the issues with the MTE project that migh= t be > relevant to GCMA, was that userspace, once it gets a hold of a page, it c= an pin > it for a very long time without specifying FOLL_LONGTERM. > > If I remember things correctly, there were two examples given for this; t= here > 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, b= ut 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-0105= d7c9343c@redhat.com/ Thanks for the references! I'll read through these discussions to see how much useful information for GCMA I can extract. > > 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 some= thing > > like swap/zswap: where the pages cannot get pinned / turned unmovable. > > > > [1] https://lore.kernel.org/linux-mm/ZOc0fehF02MohuWr@arm.com/ > > > > -- > > Cheers, > > > > David / dhildenb > >