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 6D080C0218F for ; Tue, 4 Feb 2025 08:18:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFD036B0085; Tue, 4 Feb 2025 03:18:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DAC0F6B0088; Tue, 4 Feb 2025 03:18:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C25596B0089; Tue, 4 Feb 2025 03:18:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A3C416B0085 for ; Tue, 4 Feb 2025 03:18:29 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5CF9BA0813 for ; Tue, 4 Feb 2025 08:18:29 +0000 (UTC) X-FDA: 83081560338.27.B610A7C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id E0077140004 for ; Tue, 4 Feb 2025 08:18:26 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="I/84Z+Ls"; spf=pass (imf23.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738657107; 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=FLOrlB4mupytrVlu9lHF9j5wO47m4ESC3ZgidZHHpJw=; b=XpsNcg9S42vrmAQ7vFZKIG2/llgF+R+zottQ7Da9JtkaquzyLfeSEE4GrQTvm6oiaDYpOr jcttJk+LFe/cmfItTO7iCm+q3T+RfSjOETNZXYIdv3dC7g4Ulg0j0+WPORjsRTVdz1tX1W cjKvxFI0k81CuIUH2rMIBOqLknVgWJM= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="I/84Z+Ls"; spf=pass (imf23.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738657107; a=rsa-sha256; cv=none; b=D6hzMPeuWPyaCWup6slviGWJNomywyqYaJZSQZbh2c4agTBri4YQ/RrOx/3ksraQ6ta+0k ZCziI2l+hOZGM01AIIoXgjr7KEYwL5dfXPiaak4zyhN6rp6DU51yjEGvRZJmdPJ+DuMOhn /thWbLUb4zBjnf49mzG71Fg0ONP9Lqc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738657106; h=from:from: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:autocrypt:autocrypt; bh=FLOrlB4mupytrVlu9lHF9j5wO47m4ESC3ZgidZHHpJw=; b=I/84Z+LsxOKjiS1Gme9KOeYIG6gENEvdS2Fr/lo4au5VWhKt7NH4w67QSMySbre0H2Iu5l 7qEXvab81/cJ3t66TYKbjllyqLm3ulahLbVhEgd+y97BJfFy9kPYNafFzumgmNaOg7b7GJ LSPmEo3Jz07UhiLnopVQYTTtptJdMTw= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-426--UBEsTaJO5agcFHgISrt7g-1; Tue, 04 Feb 2025 03:18:24 -0500 X-MC-Unique: -UBEsTaJO5agcFHgISrt7g-1 X-Mimecast-MFC-AGG-ID: -UBEsTaJO5agcFHgISrt7g Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-38dac77e61eso124463f8f.2 for ; Tue, 04 Feb 2025 00:18:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738657103; x=1739261903; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=FLOrlB4mupytrVlu9lHF9j5wO47m4ESC3ZgidZHHpJw=; b=PlbKVQAjeNBE+ryduK+98EHLfVaFtmVni2MatH7dpAx8VKCdKQeKoHvNAHMlQJv+/m rfr3nc//V1jyShDZ8a/j/2AXh7J3P5I2k+UM98LigqlUusbg1Xn2pRPo+vooKzeDI7MR 5LljbvRDlbcEdbY4Gk0Y3KJjYk2IAx2QdgQlB9z0o/0QiSYLvtF0PwBlXDd3dMAN5iYP wiyylzvGbOxpQSn2ADqahsNVB0DBoXXHAb/pGPlLXu92vFpOnGiVtfH/OIPNSLNR2sL4 kHZ5ZbcFGLlOCkjualEp6+5K5+O1U1nWxsBpC0E9oZNM1bOHauw3fb/uyC9Slq5srhd6 ocQw== X-Forwarded-Encrypted: i=1; AJvYcCWuYBtf1PYFlvS5lcC33EZFTOVIm4g+C1rnRV2wMkB49NUI0F3Kiesi+NMwpI0iByWhJdcPt761vg==@kvack.org X-Gm-Message-State: AOJu0YxZMrPd8WB59X4ej8ASBdjgwhap/EIavQ8jzu14RGu5bLqWl23T /t0nzSiFx1GJWG6Ne+GR2BwmUwnj+iLUOPFAnd13e+e58nV/hytfbM2qW6HbA1QotKr+V1QyBTe oVY4N9XjCe4Gt3fK/tBgOoY8NW8g/hBFrKOMlZxkwHgHh7T2W X-Gm-Gg: ASbGncsffGueFda/HyrUrrjqXC/0Cp0I+4K4NPnwLXXj5yU8KnrbuqC5wd6CUETuUSk HaZ2b5n+8/RjDVUYhQ0VLRTA4UPzuqJIJojUGoE40ttQOb7ptYgDyNjNbKydJz4daYdRbRbdz1N M9zRnl5xoS73jy1yv0c09Qerdckvu4GiWIYhEWqZt8u2Y8IXBqN1mbgLdvWjc6B/IBdz6ci+mXL 6GwGjunpVS/aHZTwC0QNXtX5xGknavnb1RIiryaCBL2imJzAFzkgsz0Yb559Ab4c7Agkq1p89CK VGQI+39DEuGR2+d2Cgrixuds0mD5PWxJfG8BXKtBaJyN5tDa+xBgVj+LL26O7F4w1HTByF4ZabC koFkpsgwq9uofBqKgJ2yu9dRrWiE= X-Received: by 2002:a05:6000:1862:b0:38d:a948:efed with SMTP id ffacd0b85a97d-38da948f73amr803579f8f.1.1738657103351; Tue, 04 Feb 2025 00:18:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IEn67HFiaRlDxiaEog+qUvuc4i8LARKzkokwmR7fORD1DmqOP7m+0llF9qtymFWW+0ujkc2Eg== X-Received: by 2002:a05:6000:1862:b0:38d:a948:efed with SMTP id ffacd0b85a97d-38da948f73amr803564f8f.1.1738657102949; Tue, 04 Feb 2025 00:18:22 -0800 (PST) Received: from ?IPV6:2003:cb:c70a:300:3ae1:c3c0:cef:8413? (p200300cbc70a03003ae1c3c00cef8413.dip0.t-ipconnect.de. [2003:cb:c70a:300:3ae1:c3c0:cef:8413]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c5c1d0bbfsm15283783f8f.98.2025.02.04.00.18.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Feb 2025 00:18:21 -0800 (PST) Message-ID: <7944006e-8209-4074-85da-14f5545cd8b6@redhat.com> Date: Tue, 4 Feb 2025 09:18:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Guaranteed CMA To: Suren Baghdasaryan , 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" , Michal Hocko , linux-mm , android-kernel-team , alexandru Elisei References: From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: nZLtn7BGPqYUgiNzsVpwJdcK0tXv_hg5MfvGTpdx5-c_1738657103 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: E0077140004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: okuhpj5cqnit7zcitwbj1ggz6s8jd7b7 X-HE-Tag: 1738657106-166701 X-HE-Meta: U2FsdGVkX18dnhsQbV42lLdQBOYIP0XdZMQ1tDa+uvnR+SmbN6G7+ILRya9aOpsthat2p22XB8IlHFfjp9BHdakvTMCw1aYPl0EHCcw8SqHHHGOLPlWY4HzS4SA3gSwZP/uRa8GXdtLCZTHMTjtqFftm3pHaC7iXEs3yoTgO4O4bMU+5G7FYjetEzxtsq9cr8s1+Ea/1vt+DNFXmSXOCkEKKh3l8JXuML/E8Mrr15NCEQkMDckU0dzKL7YPdrJHCCzF7T4UYmuT33uuII3ygkzPpo2AWtZK252pTrfxLahuOuUaB3j7X623RxFTjpsHuBmDSFcqrl8iQ8aWJlj4CZS5v3RrmbvV4VyXhwWBUMRw9xjPPgDoTtL6S1FQ+yn8oLX/eEMXoQ17Q45SzJqMmSk+aWcas05I29DqEfBDMg4dsGGuR18Ut/SFmgW61xrc/GUttSyRIQUJmNiiImGgKB3Z0ngNYTjVOrsLVSiMQbvi9d1ybRdabARDHtIgxz/EiaWZOuPn/0IopgMI7bkj4WLlkSrjjQ68Ex3dBF/GRb08NPP7bZI3yFNWc7ZRAZWMpsCJP4NOOupGeAcuZhhu/hPUd6FELkfRRXRZlCqMhhRHuivIvwfB93Gd4EJYVp77xavwvM9IKnFfxzhpaecOVXdLr52f+6g4e0IykfobmaX4sRFQb5aWrALjXWVxIAQpQuyhTXDjORQQQyHFj5PS7zNotoLYMSxsh9tTInOaN2zFvZmanve34DLcl3t5QAHRIM8Hy66/axJ1TWYcwpZnmjNWyVLvtkTVpZ5p4EzwmN549XwoeyT9nlWiu/6B2RWfS5FFZJEQx59osIuwA69wYlFlCSyObgx9oj4AysKCRNFypFvjMDo+v33xelGhX2jwyotYh0ch4CsUErn3UNEUDAM/tGA7igZCw+xSFdpyrrALem/D5PsBDck0QgXXlasE/srXU29NCW8qoDTfMZ5L l2E361pp HzCJv2hDI/bYW8UgRbeNFdIpxFjivHaBK7NX96Dd5PuBE2ObNDZm0EaSjYZPyv3qRklHISvDENvuOzUDghkTfWIXmPy+kq4hN6ranPjXywvaSarRKxXgT1Iqid51swb3f+PnG9SC3EuCxzcIuGhaQku6u4XFLx/TUlPCsuWgmUDl89V/AyDev2YOO0CaVNGwBtSxseniG2R/uIds0Wl+QnYVOvJzKH/yDmGNg+fm6dKKiHhcQImmPtKGkHMfepC2TsdNE9FXRvWJSn/35nwY/FMpTx/DenrerAizJQoWKugG1AaYSWkEXEto5/X1mTfTtCkCyDrffS7Le6KNYC7fVCo9dDZWU1/nIvZ/IVgvr7paxluwvwpAbjP9xy9bQi//Z9tbjuDjWeNIT+xfEOg3RJlpF7CvQtvfLpnJu4/VZg3cOyrpQxd0ENtjPvjXU3tiJGVz6Epg8Z+cC3hEuyMfoGsc2jRWSqcJZkmP0zMW8lBg8FRkOGiwSowLczix139qBM6rM X-Bogosity: Ham, tests=bogofilter, spamicity=0.004409, 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 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. 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