From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 5D6EB3DEAFB for ; Fri, 29 May 2026 14:52:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780066344; cv=none; b=ZNQSeE/A1oR5kQlI87Y9vv4acnDd5o3PrSxMCSwgO2hhltvgBLTkoZ6ERpaEYZMRnAr/i2zptbomls7vERCx7u1OBvpoCczl0ObLnBrKi4dAnnF5MUWaw21v+p6ZU4NKgSlKq1hGi0zRgDaBrv+h8saueKkiZpiwlZcSeR9MLjg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780066344; c=relaxed/simple; bh=pCZ3fEPjMOOKoFCjZxoSxM67ExDXIpbafDhQNDMrHi8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X2Isteg/Hg7KpqpN4x4BNB9hCiRo8N1cpRx/0PtOa6MiM9sGSWZwfv05sNmF8GrguJd8fgrfFvJDMW3Tt2FO9CjgvMuvMzoZF6ZfiDmmX9oyy6uc/9rQgu2yF4pL80TSEwBshGUgbA4CMOIIBYRY77ZbXjMybT2xkOKK0GkdUeI= 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=c8wev59v; arc=none smtp.client-ip=209.85.128.49 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="c8wev59v" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4905529b933so56705275e9.0 for ; Fri, 29 May 2026 07:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780066340; x=1780671140; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pmSOuhBgxBhu7Is1B1Rw2/yoQpGrUuGnNNhQRjRyvrQ=; b=c8wev59vAWhLrSqSBoZ0Ikjbpnq76hJ7OtUmYXGqZuFonXJ7nRg2v8NenCSlkf32FZ DDNGpfjRu55N0ypfEKZGH2cLSEoWDFa9B3JcYeoYgMMx5fM1nZxwz0XlMK+k0V63PGXD /O7ACiiP5JmQ+bfSaoGKXaPp2zXfwk7EnfeR8y5bK+BpfIKM3nIwLEN+9t9sGOFwb0sN bRN99enezj6SCJkgKT3wvMAhBLpTLhn1bANhU0Hgn7osFM5B7aiHd/9TubC8/Z2kfQLR XQlwmQHWrtxPpfWS72Iwoia3+D3jtQrEGY+rrBI6lzvgfuw9AXICaZTKNwQnZIac9tIr nocQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780066340; x=1780671140; h=in-reply-to:content-disposition: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; bh=pmSOuhBgxBhu7Is1B1Rw2/yoQpGrUuGnNNhQRjRyvrQ=; b=KQIktFz3BYtVPZ1t5D8zgnBL+9rOq8XcJhKt+f3GlNLvBYa7qbKiU4RHwBQydEeSv/ 32Opj5bmLa3qbUkwhabxE/lIcdILSEgYfR2fcHP6RikTyQsyB99YUeoWgGikaO7voATS d7SV/bVjSsBgo/TZkI+Z/ERJrdckxOHiVCY8PfHV4wSWudXG7D7lDfzztpn9tBRxM4EF TDXpWi8AvgyeEgcdux+YoHZ8lxQfvdvlUdTIeeFaeH17Ujl8zHhC+Qzxm/BLk346exeh ULfLIG3AS5BjeeT/ncI+Z+bsD2RKwYXp3gZpwOlAF2AfN4xaL43TN/Zvjq9KUTQwswax NcOg== X-Forwarded-Encrypted: i=1; AFNElJ/ELcRAXA266AOGHzfhSfoW7ErbaNnoIe58EGcJBSAlTcIbcGDch90y/Zqv+etwvKaNSO9GA8k9QhaRWaY=@vger.kernel.org X-Gm-Message-State: AOJu0YwOEBGj8iUw/QCwQ/GOa8FoKQkdgCez+RDmDWa4hWZOftZxiclw uLD0ry+mJUrQxiMNjYQQEJXU3+7qyy5GW4kCvBJ24gbL8u2hoPLLmaCCX60+N6n8YUk= X-Gm-Gg: Acq92OHdvcI/cUNi8NcUV8UGk3Vyg/apVfrUZcJfUDMT16KBC9mVKoOzgOSggMWuXwb txG1NolX2PuzOSWkUNVxHS3RhwJq/K95ge45eWxHVzp2acLJ5gBfg6uL6Uy/m2O72oC0JnTG3Yp cBrQ7ostucmq2WeyfBXxr9TOHCfy0I3IaVlMDyJror/wdtgcqQ7S2uTVY57iazLC5DRFFSuPJJQ AZsAQMSzDoyuFTFngRAOc3CcFZXnvOM/BdCqaGNoJ1XWkloCjtakvoh49Fpgb2pfQYyOqQrxR3z QmnhJv2M5goqQYoZJvSvSGdrUDpprKBvIHNl3mQRaCCvfmes1O+2TFdH54X6St2rqx7/CF/4z1Y tc7YKXPWWLCl5cpjZ5ARyPvtOlnpLz8JPSckJMzGDcsEhxNRnBQ0+Ov18EWKYnGTY5stpH3MPBx +iTc0q+GOhYonJliofFpjP1QUdUixOjaAzAT03r9pi83VG7s6Vv/yXrhP1AaMNwqja0tiOUw== X-Received: by 2002:a05:600c:1453:b0:490:9536:c513 with SMTP id 5b1f17b1804b1-4909c0b0012mr41744015e9.19.1780066339778; Fri, 29 May 2026 07:52:19 -0700 (PDT) Received: from localhost.localdomain (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909d696f25sm62858365e9.5.2026.05.29.07.52.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2026 07:52:19 -0700 (PDT) Date: Fri, 29 May 2026 16:52:17 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Eric Chanudet Cc: Shakeel Butt , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , Maarten Lankhorst , Maxime Ripard , Natalie Vock , Tejun Heo , Jonathan Corbet , Shuah Khan , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, "T.J. Mercier" , Christian =?utf-8?B?S8O2bmln?= , Maxime Ripard , Albert Esteve , Dave Airlie , linux-doc@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/memcontrol: add dmem charge/uncharge functions Message-ID: References: <20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d1407062b@redhat.com> <20260519-cgroup-dmem-memcg-double-charge-v2-1-db4d1407062b@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rw7fy7kfpwloyodg" Content-Disposition: inline In-Reply-To: --rw7fy7kfpwloyodg Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2 1/2] mm/memcontrol: add dmem charge/uncharge functions MIME-Version: 1.0 On Wed, May 27, 2026 at 03:10:47PM -0400, Eric Chanudet wrote: > but that made me realize there is a catch with > this patch set, with something like: > A: +memory{max:32M}/+dmem > A/B: +memory{max:16M} >=20 > It gets the CSS from the dmem's cgroup with > cgroup_get_e_css(cgrp, &memory_cgrp_subsys); > mem_cgroup_from_css(mem_css); >=20 > Which would resolve to A's memcg and not enforce the memory.max limit > set in B when dmem.memcg is set for that region. One perspective is that this is in accordance with dmem's limit granularity. If the user wanted to distinguish dmem charges below A, they need to enable the controller there too. IOW, the depends_on in one direction is correct. dmem is primary when it comes to those charges and memcg secondary. Another possibility would be to always use the highest precision available (wrt where current resides) and then the API should refer to struct cgroup from task_dfl_cgroup(current) (and make this only available on v2), or to struct css_set and extract respective subsys csses in the double charging function. In either case, it's worth mentioning the behavior in the dmem docs. HTH, Michal --rw7fy7kfpwloyodg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJEEABYKADkWIQRCE24Fn/AcRjnLivR+PQLnlNv4CAUCahmoHRsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQfj0C55Tb+Ahb7AD/ReCU/1qelso4Se3AlOZq R+fmGmGVDlgPYs7gBkJUqqEBALvZg8zd4ig7QW/B4SdBdSv8RGm7SPB7R9vTNMP8 dKYO =3pZx -----END PGP SIGNATURE----- --rw7fy7kfpwloyodg--