From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B89E33515E5 for ; Tue, 25 Aug 2026 16:26:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787675207; cv=none; b=ifJz4h4Wd7Hbw48lK0g2FZ3I8XaAcvS8P3nKLychQIRxSj5XKajMDcjlBYvob7daqP32b2axleoF9f0Ks/nQ5Nfawn3/GaiDJ6WlKsoq4xtmAKiqR+J53O2JcVB8mkjiP63eb+7JJwUmb3tQb9gI5MmOhjMnyroRGcrvY6s9Gdo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787675207; c=relaxed/simple; bh=fg9K1ZPJMtQO9eSSEqdgakx5ncAJu4D9kJT0Hx6NHkA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ap7YWTDzfCyjJoVt8vHzOLJR8cx12P9DOtsjk1agMBAESvZX9rmlWmQlRZhmnb3lgJVkkVT4iU2HRtYIamb49Er/J5S6F3Acz8tskJjLvwFm8oevFYralcDwSX8kunMaE2+H9N5CqtoweM7lXRjQG1UOmJTb/cptNGHPPeAEDbk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=MLv17mEL; arc=none smtp.client-ip=209.85.218.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="MLv17mEL" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c1f758014b8so546876666b.3 for ; Tue, 25 Aug 2026 09:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787675204; x=1788280004; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=k0fZPjbR+xEB7NjgLf/DwoW1nbxA9k8PLKOgb8wsBaA=; b=MLv17mEL8rRll1BGD1TXxHOza41xU8OgfAz2a7rW+B6z14GaKUzMQZADTvr38wORuS SuusYMUpKmQ9lKhgy8SBXbLH9VOsuHScKzsNeB5jwyLZ6b+7otR0aeNldaiOeYlG6mYx dbMQHR9Rzt2aE+oua3k0+aC7PonOZm1GzMZel5jyYUfunFCNNAZQL90Q4zC0Jp2b0sny EqpLnYk/AGDB3qoYOzV2o/4MqB6lNkAHOqhrmKVTE5xjX3ijK7KxmX5n/4VI7xTyADfM HoJnaS9Qz36oJqzDADvNBYitH2OOO4ArXnki6w0yOr3TDGV3PAV4isTNCgPBBOBIkqrT SxtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787675204; x=1788280004; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=k0fZPjbR+xEB7NjgLf/DwoW1nbxA9k8PLKOgb8wsBaA=; b=Ce7SL9sitSy18xHDPtZ/e7rf12PuxkuW8FQzvNXr3cbEqBhjGGz4CkXsfj0iiizq+c UErZaAV21LiaDqz02Ch+IRM6A2nyl+FoXPbkbSRJyoHyVKIxzSqCb5lo0yc1cWzcdeV3 9nwd5autikjeJ6amcG9cPiKTzuzhpw27s7LDnF1aKAGDHmYnwOkIEVgPd4vBrKa+ykL0 K0p2lkJ7i5TKN/Ac/YA9INNZMeymElziCqRReIgM6fd0tSuv0lP7DMTjbQUy9FC76YEj UUVHADFjqUGBNJQZARGmtEYY+v101dj+Bd1pvSU8qTo/BaGpH2OWRa/x9t4/af97ps3C jBng== X-Forwarded-Encrypted: i=1; AHgh+RqH4Z8KOb1P9Ke1iq8DhKVZDNp/aKvCQ+jVzP/OkSXocuo/1wCKjQWhPINelmFKSL8C10DecsZ0fftjYts=@vger.kernel.org X-Gm-Message-State: AFuF++nKsaH+aHCODOZddcBxJGmRusaCG4cEbA09+ibl7d1z4k+tpti8 jppDNToTKV4eL/00n7l4xsWq8+4T8RT1tg6IsLFFEqWuCnCo4DBQ6dwHVK2+wC8+odI= X-Gm-Gg: AR+sD11Bm8fFtyiP6XqmO4e/tqUISoQfenHx6qY2YzYkwjPIK2YQ70K4BckCc60h7YV 8JqAsFlPJcdjW5EwNY+WyJP7w7hFhGFEdheeLgDthv42RyHmmtJ2glMN2birCCuxUC4fn1SRvV5 cj1dJUOjGDriPEx/rYuKOHQnVV5Ju5GrcJEEN5BmvyU5svrw5xKA58qXwXuXFYmM//ki2yAazrN /WTsPNd+BBUEQy3OUn+5KJ9s4r/yta0zrpwnBZOk4VYQV+VXduGqABuj8AuVjIhoG4Hoe01ITN5 G2oKKBhkA0WTOj6Ffbr6YFYiNyX+90tAy/PTJjDnJ3uAvbwROuVzfehiEJh6TxC/0qgbTY8ky4H tteK2bsdMKGhuGccDP7PPQn9qWnwC3i8ZR/C0rjM6UkRwJQ9RyGQabQAJ9arcymqShN54xuBRmc sbzyx3kZ6feJiKnU4ZZwoLREYv7vTkFbKmtNydyxUdKXrabc4a39Okk9oLBTZSGCpIxbSr6Dw= X-Received: by 2002:a17:906:6a25:b0:c16:12ff:dc8d with SMTP id a640c23a62f3a-c246a69a22fmr4068886066b.14.1787675204061; Tue, 25 Aug 2026 09:26:44 -0700 (PDT) Received: from localhost (109-81-80-32.rct.o2.cz. [109.81.80.32]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c250a9b2817sm30467766b.53.2026.08.25.09.26.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 09:26:43 -0700 (PDT) Date: Tue, 25 Aug 2026 18:26:42 +0200 From: Michal Hocko To: "David Hildenbrand (Arm)" Cc: Eric Chanudet , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , Jonathan Corbet , Shuah Khan , Roman Gushchin , Shakeel Butt , Muchun Song , Shuah Khan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, Maxime Ripard , Albert Esteve Subject: Re: [PATCH 00/11] mm/cma: charge cma allocation to memcg using per area counters Message-ID: References: <20260821-cma-memcg-regions-v1-0-d21b165b8440@redhat.com> <5970a8d4-fe7c-4dde-bdc8-1c66bfb57f12@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5970a8d4-fe7c-4dde-bdc8-1c66bfb57f12@kernel.org> On Tue 25-08-26 17:45:56, David Hildenbrand wrote: > On 8/25/26 16:47, Eric Chanudet wrote: > > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote: > >> On Fri 21-08-26 14:56:52, Eric Chanudet wrote: > >>> CMA allocations are currently unaccounted for by cgroup memory > >>> controllers. As system resources, they should fall under memcg, but CMA > >>> areas partition the available space for different purposes and memcg > >>> doesn't have a good representation for that. > >> > >> Which CMA usecases are covered by this work? It would be also great to > >> spend more time describing usecases. > > > > We would like to offer some usage guaranties to userspace processes > > ending up doing allocations in CMA. > > How does this e.g., relate to hugetlb allocating from CMA, to then charge to a > hugetlb cgroup? > > I always thought of CMA being a low-level allocation mechanism with various > different use cases, and actually the higher-level users should decide how > to/what to charge instead. Exactly. There are many different users of CMA all with different requirements. Then there is CMA reservations if an area is shared and the overall memory consumption. That is why I am really not able to wrap my head around this proposal. -- Michal Hocko SUSE Labs