From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 905213644C7 for ; Wed, 27 May 2026 19:10:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779909053; cv=none; b=CxCOzfit4HKts8Qx4XEPjlve29vor4Ujv4pABxZO4N7B5ZTUUnj6s6flIbznq3Sy9zZdUgkt6W75Oo3NyJD77tQnAzdJ49VntaaDMzk4Jw1LJHDw0rvtW8ql38pQle+oPu8lMXeeSgsZN4a5T9nv+sL0755IeIr6jmMtIGm1f0g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779909053; c=relaxed/simple; bh=nAP+UkwFMeiPRtMLEhgLbQeO3ddCP9DTym3xnAPg2B0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bp+WoCUtJtQ6O9SGUkehIHPVpjEZkQXy5Mma0nfHjqHCo8BHCPf18m8/wfmAUKF7f2rQOZ5pSw46PfvKMFo9O4t/dmoHYB8BEcBqj4WLoYGnHia1YaGN7YHGV/9efEu35+0OQSO43mkh7iaFzIRFy0sakh4BaUrP5RfC3izFG8s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=b4ZQgk5E; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=sfz1h2uT; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="b4ZQgk5E"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="sfz1h2uT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779909051; 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: in-reply-to:in-reply-to:references:references; bh=fOfRGPugae13jAxurJtrxuSo8jWBso3MtJfxNQrI0Jc=; b=b4ZQgk5Egri2qBcCLwD0wfI5Hca+TXi0+3VBEQb66VWRp4itMv287UQdYbacd/1X+lj9Qi xB0tNnbqbpfCVs/2IPiNeeYj7GIyFGt9s8y+vHd8Y6aM5afZ2Bjcb7pqmSSrjrvKZsd0lL 6flqPYrUL7Pt/mKfQK6f/alE+Xy3t1w= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-453-cKO421GoPHCJEe9bWj0Dvg-1; Wed, 27 May 2026 15:10:50 -0400 X-MC-Unique: cKO421GoPHCJEe9bWj0Dvg-1 X-Mimecast-MFC-AGG-ID: cKO421GoPHCJEe9bWj0Dvg_1779909050 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-514551d5f2aso35845781cf.2 for ; Wed, 27 May 2026 12:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779909050; x=1780513850; 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=fOfRGPugae13jAxurJtrxuSo8jWBso3MtJfxNQrI0Jc=; b=sfz1h2uTS5r8ZVhzp3aKesp7EAZAfH3UbsW1sI2NyYs7CIylEt5niUhX2qj/X/xTCK Am9PBuwFlJ6txCYqkUXBzaiSDntjA1e3TgirmogUimEf2GNn/C8wTmRCacYylRy1UIUK SvMjAZcKBrQLnkj7kMQKcMuRWhNNmMH0+JyijRKiZJV8K2BU/fu5dwXUzS0vdECWT/0x LYbtt1TzW7RFmp+lVrrBuNmilhFjK6wb7lsmVo77yur8IufKReR08ygks+j+tx+VjVk6 WHDl4CDOZKHxsi9a8w1pJW+TrsRiX9L1KOpSz0+PIbwEP3VGCjpohtktgV1driGm8u1Y VdQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779909050; x=1780513850; 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=fOfRGPugae13jAxurJtrxuSo8jWBso3MtJfxNQrI0Jc=; b=m+qLs89LSv1iB5yINEZC2hvBsSdBwMaVXi7qx5xpII1MrgwPzhDA/0jaa/h8FUuIhA 96FRPZbb0NHbGDvzvA0hdeGZmZxeGCb1IBY8A8DsvzKxvtnRUalRPwFSS0OI52cmVUx3 Mckhkrc/yd0n1Mlea8w6cG/l89baCv9xL5crDo9mw0Evr8KlevJFSaRMuolSCdD7qjyP YVrVIzoMo95uQrbH5QzXaNTXmAHklI/l7/l0kCW8ZlmH+EVPSiouQd1k8FCRVwFdeFqJ tB27WPacJuE0qcIQtoVPcpBNqcYcLn6kWy9ifsUz7Y40oKmdPtHTz8nDT5WszFI3TuK/ 06dw== X-Forwarded-Encrypted: i=1; AFNElJ/q4UTm/iSxDNpBiw60MoooM92zn8a6TG4GH4iIvTAOUM1a5BrIcKj19Dh/MhZI8HQwX+2tMrrfIJQRvtg=@vger.kernel.org X-Gm-Message-State: AOJu0YzFsTmGgonRlZBilEl2c6NxfqXk6vQYpuEGjpgfwjLArNZzOGV9 EikH9pmCM+8TjaRtT1/DM/iRssYmpL0RwrNPmMtk7/mIml9xrld5vmHcPIPJxUTpUTjv4G5lH+J GGY5g9U+vxe2A/5hHnWRy8NDJXvGl+W+numFAqdF4VzN3o/r5JBa7njbDpsF+2dFG0w== X-Gm-Gg: Acq92OE3d0pWUiY3HQWx2cSiy2v5XpbgcrkcoT3v900wq0OFxSEODc2m9vUO8GrbdeJ LOUPNGNoISuRhJ+ogvl44dsreO6GtPmxZZwuJvTFPyVkhetLACL8SrNHmrz5h1lgwt5BV2qdVc7 TpqOR3zvDKTNGfzIkPcLtJWgT3vaZ8gH7+G4fDb9dhiE/5pGCmsIzqprPFyY2eOzFaSjPYSsLa9 Jt4025O1CUZQb8P08nQo6By0k8xmAlg0quzr03n9ey+/oFSvqMP/LfqyRzS17oRnm0znDA+7qVg u9JBpArcnEThTmmAjhaYIuJ+0KAAICCu0dw9fPwoXQMC84WAn1SffcZiJRlbsVNVfNEjT0YbV6a iZUCkCVPfIWbOwPCs5NvsH0dk+Q0jCJHZZCHigLElvUbJIox8i6PDXzVMDo1S/mP6DZXXDgNpys Lz X-Received: by 2002:a05:622a:2d5:b0:516:4fc0:27ac with SMTP id d75a77b69052e-516d43e4561mr348875421cf.50.1779909049460; Wed, 27 May 2026 12:10:49 -0700 (PDT) X-Received: by 2002:a05:622a:2d5:b0:516:4fc0:27ac with SMTP id d75a77b69052e-516d43e4561mr348874431cf.50.1779909048607; Wed, 27 May 2026 12:10:48 -0700 (PDT) Received: from localhost (pool-100-17-21-205.bstnma.fios.verizon.net. [100.17.21.205]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51706adc8f3sm51751971cf.18.2026.05.27.12.10.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 12:10:47 -0700 (PDT) Date: Wed, 27 May 2026 15:10:47 -0400 From: Eric Chanudet To: Shakeel Butt Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , Maarten Lankhorst , Maxime Ripard , Natalie Vock , Tejun Heo , Michal =?utf-8?Q?Koutn=C3=BD?= , 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, May 22, 2026 at 08:53:10AM -0700, Shakeel Butt wrote: > On Tue, May 19, 2026 at 11:59:01AM -0400, Eric Chanudet wrote: > > Add mem_cgroup_dmem_charge() and mem_cgroup_dmem_uncharge() to allow > > dmem pool allocations to optionally be double-charged against the memory > > controller. Take the struct cgroup from the dmem pool's css as there is > > no convenient object exported to represent these allocations. These will > > resolve the effective memory css from that cgroup and perform the > > charge. > > > > Introduce a MEMCG_DMEM stat counter to memory.stat to make the cgroup's > > dmem charge visible. > > > > Signed-off-by: Eric Chanudet > > --- > > include/linux/memcontrol.h | 16 ++++++++++++ > > mm/memcontrol.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 81 insertions(+) > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > index dc3fa687759b45748b2acee6d7f43da325eb50c1..8e1d49b87fb64e6114f3eb920293e14920290fe7 100644 > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -39,6 +39,7 @@ enum memcg_stat_item { > > MEMCG_ZSWAP_B, > > MEMCG_ZSWAPPED, > > MEMCG_ZSWAP_INCOMP, > > + MEMCG_DMEM, > > MEMCG_NR_STAT, > > }; > > > > @@ -1872,6 +1873,21 @@ static inline bool mem_cgroup_zswap_writeback_enabled(struct mem_cgroup *memcg) > > } > > #endif > > > > +#if defined(CONFIG_MEMCG) && defined(CONFIG_CGROUP_DMEM) > > +bool mem_cgroup_dmem_charge(struct cgroup *cgrp, unsigned int nr_pages, > > + gfp_t gfp_mask); > > +void mem_cgroup_dmem_uncharge(struct cgroup *cgrp, unsigned int nr_pages); > > +#else > > +static inline bool mem_cgroup_dmem_charge(struct cgroup *cgrp, > > + unsigned int nr_pages, gfp_t gfp_mask) > > Please follow Johannes's request to pass the actually memory object instead of > naked numbers. Sorry, I misunderstood Johannes' comment. I am not sure what to use here. Since these are called from dmem.c, they don't have access to what was allocated. Looking at zswap, it uses obj_cgroup. I thought of resolving the obj_cgroup from dmem_cgroup_try_charge and keep it in the dmem_cgroup_pool_state, 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} It gets the CSS from the dmem's cgroup with cgroup_get_e_css(cgrp, &memory_cgrp_subsys); mem_cgroup_from_css(mem_css); 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. -- Eric Chanudet