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 00722C02194 for ; Tue, 4 Feb 2025 16:20:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74B816B0082; Tue, 4 Feb 2025 11:20:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FAF56B0083; Tue, 4 Feb 2025 11:20:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59BDC6B0088; Tue, 4 Feb 2025 11:20:48 -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 39CF76B0082 for ; Tue, 4 Feb 2025 11:20:48 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BE893B153F for ; Tue, 4 Feb 2025 16:20:47 +0000 (UTC) X-FDA: 83082775734.11.901B1E4 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 52BECA000B for ; Tue, 4 Feb 2025 16:20:45 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FKzBnHkb; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738686045; 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=NzE6KeYgkdxHAsIxVV/w+ZpY8zxAFVjaD/ORnl4nY8I=; b=ryDILSfpNg5p5ZMi4hF4dELKL9XJM1uvNzCwB0v4Whf/SOcnRlhcPhD7y1qANilanFJ/Oy R6z+ce45JYSiUEyQIn3xHOsWToNnbSg2zyJsCfMP0+dWRVeQUWZSfAn8p3Kmzha7/LVlh3 c5L9LgZjSW1BRHRZSTA4KfMSxi3F+Lo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FKzBnHkb; spf=pass (imf15.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738686045; a=rsa-sha256; cv=none; b=1DOdjcCYxiPfgGYYE3WnB1zVsZdH2xdI8F113XLY2xtn+FDXAFf1yafZg4h3d60fDTJjgT B69LtM9Ais5EMGH+/UoOVesYFLJ3JfGF8d2BdbexeLOj1hPYqLII1yCi0ZZVReSi7Vovz1 YWWpdBUgi1APZhpqZBR+FcGc95mnzLg= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4678c9310afso224741cf.1 for ; Tue, 04 Feb 2025 08:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738686044; x=1739290844; 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=NzE6KeYgkdxHAsIxVV/w+ZpY8zxAFVjaD/ORnl4nY8I=; b=FKzBnHkbY9+/2BVTiD/g7yFsyO9o+IVQPqjEA6umlxR4i+YL+2Xh7kpbQSpwWYWTGZ jErqHIdkmCIPb3n1N/gzQUe/lVoJEKkDLq8hJWOwz05rwL8JpotfnariOEsMPIRCV6Ch ZYXu78C9kKs7jR4DCdJTUDklyxuD32ztRTOeYkPvkWf+edOAEustxdZSqqnGE9qNJFYB fkj/4wNL2ALGqxurbmZiCF1gQYIXDcbRp9Nq/o4XBf0yjxwyP51H3Z47S0gWY8/jAd71 NhoN8Hz1ZPiLXSgNAkeRzkv0u8Fo2DxX7OG3vkvPF90deBrwBbup1Z9hOXe9jxfx/XEH fa6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738686044; x=1739290844; 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=NzE6KeYgkdxHAsIxVV/w+ZpY8zxAFVjaD/ORnl4nY8I=; b=UxA9G9Ve7fm5GLJSkYZ9VE141AxJpbIBBifJMdg1fMIVEIZ1z0DsWnpfl8IQMI6kcq OQbnn20vHrd1bHskTbU/dGBmoSTEhpV0BvCMN6U06guH0yWIGEwO/GGsTsWIFAKhtuOs R5TpCiyg6qXfe5af+JzkALPFp9HKnEaPdGUF0KWb0zIli0ZG2u2BPlaaC3pQq4KaH99y MFZCUMFx3D2VhS35mwUFoRyNFFpGFF4ti5s3xwhDlmDB445RQDOneGTu1r8IhgpbFovj MBaNWybJfFXt26UtvDpaCaZOsuB8M/1HFKCoOK4eK5WjdHH7F2T7I8vxFqKfJLcbYHaR OX/w== X-Forwarded-Encrypted: i=1; AJvYcCUy2HftlW2XqPYqye2dmaLVjTJAxdkPwOU85VuCXlolb+GVSJLIn29w03RhmL3roNxysJeoLly0lw==@kvack.org X-Gm-Message-State: AOJu0YzsKd/M1uz81HiprjDb0XyESI/fKIgqYYnytrtEyiQyAULhuLim Sw+KZlPvaGTqZ9mwq0811nhJ+fh8GLsVvnv3oYFKBwNJMhGODMuPXmoI2Sk3+4FOCmYgXqHGdYN zRoEnuAWE9ZvMrMXU2IBjJa9AhUlqLYQWinKG X-Gm-Gg: ASbGncsE9XMmIzigWtVy0Ywo68gwhZXqARxXHQDvHz7I8JwiKRVTg3MTXKzsCl8TZet o4d31okyGsEJJqap4PFWNLRK6E+fnsinqo9hy55GV9nGUDDATJuzGndiDp6O66gIlfdv8l5QKWL 9cbGE5jbPDELgXmrj9xSgJSfcqLyI= X-Google-Smtp-Source: AGHT+IFr+TLzVfPO9yZeFpWpBu43aY6WagA1aQ96HCuh+9uZN316K+vPmrlzDSnrWc6j3OSDH6NpRJtG7VZ7RVkjX/k= X-Received: by 2002:ac8:5d10:0:b0:46f:d59a:1db3 with SMTP id d75a77b69052e-4701903a951mr4648601cf.12.1738686044070; Tue, 04 Feb 2025 08:20:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Tue, 4 Feb 2025 08:20:32 -0800 X-Gm-Features: AWEUYZmWDGf8WtkShOCJhOMfBICMwqEXEftchKuM4VSRYAt-gmwIR2Rsugz2Q9c Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Guaranteed CMA To: Vlastimil Babka Cc: 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 , Lorenzo Stoakes , "Liam R. Howlett" , David Hildenbrand , Michal Hocko , linux-mm , android-kernel-team Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 52BECA000B X-Stat-Signature: wuudbss9qottx1qk9bcwfc1r3t65m456 X-HE-Tag: 1738686045-903220 X-HE-Meta: U2FsdGVkX19p2LvULJZWK8LLl6KYbA+8GYEYksBNMj5pI0IdQLiayTNKQ6Wx8bJ0jos4WJU/c9mz97al6Wwka0z+5Y+yhYUscdN2M+14d0bJNT77U6J7TezJC6jf9cUWC43Nd8uXAYcHK8fcFWvQvcJ9qvVcI7Lpjgs+Q8+bogu9ehAvUp4yUUYo/1ObnlJv5FSsEVOJZZDQT9OTC96/vHvPZA3bHn5YaytOoOxP6wnfIkskaODLx/yUkdEVGWUq5Z7GGLCew3OEbeNbqErWH2GPEP/wjyZ6Aa7uDzzjkzJDtOUpg9AURQY8z9vGXQa9Wf3Fh6BkaLIfLDGnSUPGdX4AJNH9inpRptdx89kHpub++bxyoLXq/xvFWYlq7b6+1570yIebGY74rM4/I8ozSP86qH3doImEesb4vyfCnP1ZxjUl3m4olvBSIOtPG9fCDxEFKBa3+f1af83vIM9VTvf5g2suSUcT5IXJQxxfq1w8IHCPG6CRPQMPAlku2Zk9o3Zc0p4dm86C7gm6RWmkmnPgPY/pUmQE0R3VKcWSqdRoLAjt/UWA1QhSwZ7rIxQq4ohYfsFzvHjmua4xA6dX1+X9U2T4XbxOjHOhLwtKkDzcuu+5tP5OMdX12KU2CCpXtKD+GiXXH582Jr9gfkB7DZhI4FGvplnX8tZJKToReU8rsoOgN5c6WQyQv3PCxqCcKFCB94KPBDOPh5scmx9LBUz9fQR7aVFK2TH8AWGxSxrptbcoLRS41TlMYheCuIm60mYrIU7xzipaxo/o5PPpcIZtWgTprDOeQRWR1TyTjN/6BbYZtWF9ytGbc8xGscLFEV8HuTGsM3tye1lBWjNTu++cbZJZ0pZDfKzuoQMIiQKrZL1Bebz5HEOgqofmnHkdbwtaUMvuDVjQtaQjfmxcb4Hq19JEtZI4xr/zY9AzY44wRdyqMNl20/RSK79uOGH+ZpiYydaCHhtTaCFsXr7 wEeOO4bo VOYTl32Xre8if8Xo3xQ+FMwzD9hZArgkvGCUvsvGw3gykLRmNFPzu9UMSpBHcSAm7ZLbdnk1d5F1k+zAJ0JqaG68YWt1rYf5s5nrAcmWh9x9cfxQJpQ4GaH1fhk/QsNMwaXfB8tHGuI1KyceJNfu8O/6rOlpNMVFiP3XXFlEJT+xC1zAKPU6vyCD6c3XV6yY0w4MMHUC3ILQk31DYTy3GqYMn9qi4GNd2cHt/bWovX2yA6wSNdknmhBatTLRPjGliM7b+D3cAp3Uz64YFnqT7NQ0zqh8oLApSJ8rFJ1zTBaMKh1QhYcNa9uBjM3iOT+vPb2jUHX4VrcDvvxxaDGOydxQIwh7ZblIFLMWV+ENqG6Ba2N7u872g9memgL2Hj0oijujVxbDskIgj8mbhfyYnKNtWfw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.008860, 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 1:07=E2=80=AFAM Vlastimil Babka wro= te: > > 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=E2=80=99s otherwise unu= sed. > > 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=E2=80=99t take a reference to pages from th= e > > cleancache, therefore can=E2=80=99t prevent GCMA from quickly dropping = them > > By reference you men a (long-term) pin? Otherwise "no reference" would me= an > no way to map the pages or read() from them etc. Also there might be > speculative references by physical scanners... By that I mean that the cleancache memory is not addressable by the kernel, see: https://elixir.bootlin.com/linux/v5.16.20/source/Documentation= /vm/cleancache.rst#L19. > > > 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=E2=80=99t know at the time about this use case) might complicate > > upstreaming. > > > > Desired participants: > > GCMA authors: SeongJae Park , Minchan Kim > > CMA authors: Marek Szyprowski , Aneesh Kumar > > K.V , Joonsoo Kim , > > Michal Nazarewicz > > 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@gmail.com/ >