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 307F147010D for ; Tue, 25 Aug 2026 14:59:57 +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=1787670003; cv=none; b=nubeAN1ntQdjzFXlw5q6d8VGiuVzqBTbo5q4BvSdFhPzZlr/DEYnkQvYMESkxjOotQ9oD4gs+gQvp7i6u/Ojo0lkkokOB5vX++a1ZX/bBQzh5H7ZGdpMSSUc5A5+C8WejYWBFi7vuybR0NNbCsdsU5wGLUGhvr8QUqa/vnuMqys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787670003; c=relaxed/simple; bh=Dpw4rtPNIhmMqn7wNJpVZncgvMPX1xG1jtECbsm5Vj8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gTkHTv+0miIoDqPmM3dm55oJO/k8m43AMlEyb7gAKb35zIPkzGtoD2R7Mn+HKtlDveBZL/gqw65mnohQ1vaKKAV1gpVumYikhhCzS32L0jSQv711+Mzq2aCDD29NmoArV5mqvPgGMQdimOGVShUO6hsRKSBq2M1VdIjEn786fqI= 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=TaE266Wd; 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="TaE266Wd" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c214321dc32so946298466b.0 for ; Tue, 25 Aug 2026 07:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787669994; x=1788274794; 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=06QgDRd3KsQRNkIC849obH3kyg/ANunDmHU+Cwu/Xpo=; b=TaE266Wdpq6iQsaokirOQEe4P7Up3BdlXLynmT2tdAbixOEuLgylVj3/ONXvl240Gd XOLYm886a43G/NjFMJ33EcK8dDdAF8cWS2NjjOSAOCi/rn3fBe6u1Xf46fSqOz0o12vP 0NCt4aZ2NjrKTVBvUJcnqgg2YsyNY3FQf6ac7Ri5KEa4HPcYlg9grx4a/Bh2eRo/ySMh EfRT/nmlHsNWGm2LzStmUJKh/TnnICIE1HpJkousfGkVO80IXxLWxA2pGFPVoaN4b/E0 OON4P1FJEenXJhGzsZd3QJewKyf27NhyFqrq2x7/1/1Q9a2TThPF5/J+SdFoRzCBHCuh SgLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787669994; x=1788274794; 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=06QgDRd3KsQRNkIC849obH3kyg/ANunDmHU+Cwu/Xpo=; b=Fmd486nZm/gQcUojFICRs1llowvDhtSV7SAkcoZFS9Q0TvsuDn7qHx0IcsXain28Y5 i/hOegwydCZBPVMunrST+nKOcorerKiUoDLlP9bh0hmDFy7fImBBpkAaFvBWzl15Z4Bc STuHnJw1X7qZCDaZ51V9+gNaf9I68IOA+doYmOambZwQs9juI9egzsvA+Za8gaYg8T4K 7h8PcPott8LJEI7OFORDifsoGxZ+XbmPtLj/MORrr2pIwZkal/FtSJGtzhplGURLyIS9 g1Yw4R3en16+SWU3rxbTVcVhL4DpDAqHymlG1FjiK0T2aAGGJoWei7OKBfTVkES9tOXx VIjA== X-Forwarded-Encrypted: i=1; AHgh+RoaOerxER7w5fViCZRZqfhBUp2ol2LoRaiYDjrvubLAzjeJDCzV/JP6aMzlAWavQpWRlBZf8X6CMBOtmb0=@vger.kernel.org X-Gm-Message-State: AFuF++mVrwEHaYCg9s7slgVRGAPOB1TvNmoRVIRPKG3D5Uj7qMsWdRPo amcvAJh9CXq9oAvuuL1LdfY0JVR9mgx1Odb74C9qzdAl0I5WI0ost1vapICm+vjBjbw= X-Gm-Gg: AR+sD13QF3jEnbCKHj8LnVG+cI4aJIuo3JKnq3x82C87lA+XGMDsXoJe8msfmM6gj9a j0ZsSezNXm5zHF8KTqo5srbx0Nys4aD+a9Cz2ek0e16lJsmEHA/d4z5PEgPcwJih9Lct7G6Fy6Z gL204sCvJ4+ds0OR1XJ8o8zma9ItzsCHojx5Wflt2xjiTSs/kGojvzSSIrB8l9KWxLlbQfwoCaB ygGEIGAwFnJXE0+Sa3k2Cef/fuJJBwMVRn7s9zVgIHpxdD9yT5Gxn2luB3as3xYnssfLYahYtoO vy1paLkpJD5+QQI1sbT5xJ9uHmFszwhCT/yrE3l4tMCcDitDNg5qQKFNdhUySuJc4av4GV5OJH6 s2fB0p/UIfaOUs6j2Y9KKQMfT2S9k+pNspcslMqtLiliOgvfJj3UyZlxcOxceWotui6wooColR6 J4a2X+afFrwMLlZRXgGI0gxVO3ENh/64+dWDvWmFiYXfNNSf8nPZveI4WPF/S/W/dLvHAZIwc= X-Received: by 2002:a17:907:b048:20b0:c20:1c9c:b36f with SMTP id a640c23a62f3a-c246a4b154amr2894042866b.8.1787669994328; Tue, 25 Aug 2026 07:59:54 -0700 (PDT) Received: from localhost (109-81-80-32.rct.o2.cz. [109.81.80.32]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c249606a905sm2134790566b.13.2026.08.25.07.59.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 07:59:53 -0700 (PDT) Date: Tue, 25 Aug 2026 16:59:52 +0200 From: Michal Hocko To: Eric Chanudet Cc: Andrew Morton , David Hildenbrand , 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> 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: On Tue 25-08-26 10:47:53, 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. > > For example, a shared CMA area is described in device-tree for an ARM64 > platforms. Userspace components could then, for example, allocate from > it through the dmabuf heap, or a device or framework-specific ioctl for > that matter, to use the buffer with sensors. The dtb may have other CMA > areas described additionally that may or may not be used by that > component. In this context, we would like the ability to limit one of > the userspace component to over-allocate and choke the other(s). How exactly is this supposed to work? How is the CMA access controled and opted in for accounting. What happens when memcg limits are hit. And many more details, please. > memcg > looked like a good fit to achieve this, albeit handling the areas, so a > cgroup has a quota in a given CMA resource. Please expand more on why do you think this fits into the memcg model. AFAIU we are talking about a unreclaimable memory and reservations of CMA areas. > This trails from an earlier post where we tried doing this using > dmem[1], but I was unable to reconcile the requirement for memcg > accounting[2] since from dmem I didn't have memory objects to charge nor > the guaranty there was one. Given CMA is always system memory, it looked > like a better fit to try something without dmem. > > Best, > > [1] https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com/ > [2] https://lore.kernel.org/all/ahB7pCu_G4vuswc0@linux.dev/ > > > -- > > Michal Hocko > > SUSE Labs > > > > -- > Eric Chanudet -- Michal Hocko SUSE Labs