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 78533C0218A for ; Sun, 2 Feb 2025 00:19:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 881E76B007B; Sat, 1 Feb 2025 19:19:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8308D6B0083; Sat, 1 Feb 2025 19:19:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F8BA6B0085; Sat, 1 Feb 2025 19:19:40 -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 51FA66B007B for ; Sat, 1 Feb 2025 19:19:40 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A4C431408ED for ; Sun, 2 Feb 2025 00:19:39 +0000 (UTC) X-FDA: 83073096078.06.73FD398 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf24.hostedemail.com (Postfix) with ESMTP id DD94C18000D for ; Sun, 2 Feb 2025 00:19:37 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="qF/ObzbH"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738455577; a=rsa-sha256; cv=none; b=1c4hqUQg0ikKTO115T6O4fpo/gohr1t8p3K7oIBulVDGGVsGjzWiZ+No4zbeQxLcJ2EktX ccLDXCNaeuFOLqEZNot3IVbTCDJyqFzODxG/Yw0W3WYkKiXK/IweSGfBNuaWxsCqKniJCN PfVIK08Xiqz0JhWyDggzkScwEcGC/hw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="qF/ObzbH"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 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=1738455577; 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: references:dkim-signature; bh=WeE1Mf8w78uFe72hwVdggR2x79YXQYe75blZXvlJRbY=; b=U88jjwCZ6iW8izIbGFdd5ItWPqSK5Q4ZQsMll7pNNEK7OHw92Xo2FCAHGOKo/FLI+jCMUi DJnuh6SHWby7It8mBgNDVIeS5vcO7oPSf6BLx0TzxEzB/yogNbIrdxi4gQ2ro6F8lAPS42 2pVeaSN5FB139Z6URaD9HKQZbmcAnag= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-467abce2ef9so216621cf.0 for ; Sat, 01 Feb 2025 16:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738455577; x=1739060377; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WeE1Mf8w78uFe72hwVdggR2x79YXQYe75blZXvlJRbY=; b=qF/ObzbHXWdLCLNNdGT8Y9wf47e6Bh5snt3dMo1nvY7lPYqnJ5wL8AF9S4tWER+afH UhmFhrwu1B71h9ebzwfJXhHeCabQgptm+TAO6DNFcfJNOD3Mzt1Buyln+lotp5nepmHM n0429s1fmoMCbjFVFysmTpdIwvqIt7VusU4bixHbkC2fcXBWAfpsF2+Y2kGctsTjP2vV A+rTminUsGf5efQOGN1BKuZ3ttzkxXDj6vr9ZJtSJtBxmkfXJ9Ik/f3HNjatqgZrcnss dfuQf/wcmRhxahS5gB5Rx56340gFpKRMoi/8i8srTcThVxm+y41qXvqNVb6EFVhgmpgq SFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738455577; x=1739060377; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WeE1Mf8w78uFe72hwVdggR2x79YXQYe75blZXvlJRbY=; b=MCrl4GljvCuvckX/pHS7vqZAr4IJp/UgxboN66yLPI2cT6p7NZjVK95TBHANaZ07Ol gbesF8+hSY3WfS9hKv7LxAsMEwQrXaCTGYkB3vzBVHQdr9pb3RJD041D9BXXTVZxHRTh EmZeETn2LcFTUzHkL6zZnYdUnTRKkXxFj9sY3DFzeXnOctx8xDlnH5dW0Joye1Wgc+7S WgllZD3vWS2ZK6xw8jN3yEg1gU5dET9Psl1qrsOtfPdoD8xPyg/5Od8Msycksjo595Su N/i4pwBtoCqtb0cFRx/MkG1XQIpfdH8EzXuOkPoFaQpgY4p2WjSpgs+55dGiITsGWg1k iRPQ== X-Forwarded-Encrypted: i=1; AJvYcCX3H+EIfxmUSUv7un68dsrPlEPZIuJzKRNsleApYZUoYlu/614P8ML7MuoGTTakuog4vhUD6NS+wg==@kvack.org X-Gm-Message-State: AOJu0YyqdvarMgpknozGmKQftPipm2mySHcfIDY6GrnJlbNWs+qJo1G7 X+cObng7YoZYQDouW0EfqTP1xU/XlnxCFnOI8fg10N+/akVBATo1y4tM0wBIYtp/vNwX386SL3u HHtfebVtS5SpJ82pxK9xE2hIT/4jm4PWyAkjO X-Gm-Gg: ASbGncvvgmkbhFT3gvoxFpUXB/hs4Jd1vXBQphFO0hWtrxs2CiK7nqwn+8oxC4gAMQz 9ZCAACPNQu6fMsdvDL5DW0z6Hbj9vo20NUWEmcwwi3n+pTPGkbXzSf+mFU06ZOUU29NOhpQ78 X-Google-Smtp-Source: AGHT+IFMC8ckCT43pFVNsxvfutvL3hHgsKKrHVvPUZPGMXdMOqrBcJMBS+hZp6o/+q8OPL/SSNXPHGJWfZJYjA77YnE= X-Received: by 2002:a05:622a:1805:b0:46c:726a:14dc with SMTP id d75a77b69052e-46ff889a3dcmr2884261cf.28.1738455576650; Sat, 01 Feb 2025 16:19:36 -0800 (PST) MIME-Version: 1.0 From: Suren Baghdasaryan Date: Sat, 1 Feb 2025 16:19:25 -0800 X-Gm-Features: AWEUYZlgdZXk9djbAxaIPQc3vt0Yuf8fUaNLPWcRtogskL9SUMgYnmuMKzNcIlY Message-ID: Subject: [LSF/MM/BPF TOPIC] Guaranteed CMA To: lsf-pc@lists.linux-foundation.org Cc: 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" , 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: rspam01 X-Rspamd-Queue-Id: DD94C18000D X-Stat-Signature: 8xituk5ochkur51dj4cc5i4f3an7ywhc X-HE-Tag: 1738455577-211656 X-HE-Meta: U2FsdGVkX1/V2M1Q7D4nQnFDsFcxlaQ8h8RAL29PzHLWft0Hm/+kcETPW7l7XxgTalQ+Q7M5K1KK33P/Ns6mpE0WKLNeyCcAv0onVq5S1bvpZ96x0/spf/nb5dt4Ag4uNW3LYOMKAUt/gNb1yeyxdgfF6kHskDJzmvE07o47PoXBq9BEKQ6Eciim+7RcWi0i4YljtKKoR1kW7VftQavVP/QZRM1SlbHYEMhUX/Q8hdp+9sEW2Qm92sKyy2tjkShOMQKRq1RYQPBd/QDtuDDvQIBZWvkMoZ3MMCYpj2iswQID0IJfvFeqLv9prrmG6mAjJRo2OaW27pspKxjFGIH7JorSa75HtyWxTLzWLl5//Hv0Ir17dZV7mg0MmVjqSEaPVS2rnOFMB5hFVKBe4HGNjYhT1LSW1DFSpnNWDUaQoBdlnW/T6ML4ACdOyteGanC1ps9lf71w1nvaJ1gex5hCKEzXcQocFPIJlw4OauzwCLyNZDbVJ0J8uKc5uN1+JGyfMuQAgS0SIS+PnrPDSWY1WoyaaV99U0XfX2EN/7FkGQounwrGvZp/ZXC9h0vv/HK6rUjAgwKJZLETuckZ3H0D3dA4VApbupZ8OLiYJjNZs7dmKzg/yzDsKJp81nSsWTF9kDQPNgiEoK8RANF8kVQS92k900M1olzSvuF/ZM5dD0CQ1Wnv4QTUBQ0oMftYY2pfcBGPGaXMWwucITyVRijTjZ0k4LcoDLp10y/qIepaOu5dGXfAyZBQkkXyMSohAwLUzdbpIBwDtBv1xUhHjrYR/w1QivGBgVUl1e2ID5x9kXL9/zbVcQNY3/SJqOEXOQ4UV7jBmaKytAkKMpI1aIB2tT+a/cHqq1ch7gpMw8MEqYXrIORoIVZNIc55tcLRvUNqJwxcsRWahCF3IMC7suC+FAaAZ9xEmgPp+K5nfmP8d5io+9ugy0VoN8xCTWHNjTpUIvHRekrN1Kv0h2n+MOZ Wsk0zbBE 5SDugg1gMpYOPS9/GfkZadtfJFgydlzrDFgohWtxcbqXZPxVT+9i91nA5CVHTNan+bkMjPbo/wRR8nONv5WFB5DwpTH8zA1dsL7+Anuo+akkPRUvOSpX4Nn2D++t+hzkBGF5zjDACZ/jqOncOBXOl4rfonEzSsQlExRTvs+otIt7sYj2GL6Y5X4jzJRjeACKTpLSNyLv2FZzT5BrTKn3D+WkUx4c9MTW6mHoDMDko+18gUjhkNtraSqd5uXDKuEMZnop2vgydPwIjWJryKZHZUP2Ba48GDVmCOFt+eecYTE66gIVKCK522PGJQPFyP2sJlJUReq4jI7qh4+bY0k58u3qHV0b8c6CjnXxS X-Bogosity: Ham, tests=bogofilter, spamicity=0.022671, 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, 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 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 the cleancache, therefore can=E2=80=99t 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=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.par= k@gmail.com/