From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-165.mta0.migadu.com [91.218.175.165]) (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 4D56853976A for ; Wed, 23 Sep 2026 15:47:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.165 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790178443; cv=none; b=YzR+qzSyblJ1Fc/othPp7pDdCj4TCLxn95CWbUEqJzetj1UeZ2J7lekwF05bA2eRpU29p9wxfQ0dfFelawaBUwQ4Bt/m8o8bE4lTQr8gY3V2a8bTSBXP0qJRGokVe4/OWlDleNU6N4TI+RMZY1gIFWlucre/CDt6P39Sboq7CA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790178443; c=relaxed/simple; bh=HNkEwA1ANe2Cy1ef5VkR+k5aNsAR9SDnOLDe/iDUfoE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lYAJ0zCyZ2/jqTKtRR1NiZ/jwokH1k0q/KJrKpNdrA4I05Lm70lCfL3p9dGdfmmHpKSaEMrZbY3MLk1uH+Cmlb8cND6O7YNcCBpwDQ0vd9AYQHFRVGS2hDT3yOVOBxMOn+UgJSXlpDGAMIdmeC24NYmW3kGUqVgGIzmLK1nWUwY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=gK/6DbpA; arc=none smtp.client-ip=91.218.175.165 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="gK/6DbpA" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=HNkEwA1ANe2Cy1ef5VkR+k5aNsAR9SDnOLDe/iDUfoE=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790178439; v=1; x=1790783239; b=gK/6DbpA5mLun8HfaS0RPh07yI9BS6uvaiXwxcf4URpNyeOHH3l9Cizm02q+9l4WbNCfpyNq Gei+5dxy5AbaydJUMUhKus3pqAgJOB9Fle++kwSW1Y1h9rW0EGsOHA0mBNEwW5YBpGbVojbGrb+ vp8pLFvwP+JRvXceviDmsU+M= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id d5fec120cfd73ec7; Wed, 23 Sep 2026 15:47:08 +0000 X-Mizu-Trace-ID: d5fec120cfd73ec7 X-Migadu-Flow: FLOW_OUT Date: Wed, 23 Sep 2026 08:47:07 -0700 From: Shakeel Butt To: Yafang Shao Cc: Andrew Morton , Alexei Starovoitov , Johannes Weiner , Michal Hocko , Roman Gushchin , JP Kobryn , Muchun Song , Tejun Heo , Michal Koutny , Amery Hung , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Emil Tsalapatis , Jiri Olsa , Ihor Solodrai , John Fastabend , Jiayuan Chen , hui.zhu@linux.dev, Donet Tom , Greg Thelen , Meta kernel team , linux-mm@kvack.org, bpf@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] memcg_ext: memcg policy through cgroup-attached struct_ops Message-ID: References: <20260921192559.2619635-1-shakeel.butt@linux.dev> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Yafang, On Wed, Sep 23, 2026 at 09:07:40PM +0800, Yafang Shao wrote: > On Tue, Sep 22, 2026 at 3:30 AM Shakeel Butt wrote: > > [...] > > > > Known open questions > > ==================== > > > > The semantics of memory.high for remote chargers or kernel threads is a > > grey area and this series does not aim to resolve that. > > > > Another open question is whether a bound on debt deferral is needed. At > > the moment, we think that rather than putting a limit on deferral for > > memory.high, it will be better to handle that through an async worker like > > memcg->high_work. We aim to introduce that later, along with the right CPU > > accounting for that async work. > > Hello Shakeel, > > On the open question of how deferred debt eventually gets paid: would > it make sense for the policy to also notify userspace (e.g. via > ringbuf) when it defers, I think the notification through bpf programs is already possible and a bpf program deciding to bypass memory.high can already do notification via ringbuf. > and have a userspace reclaimer do the reclaim > through memory.reclaim? > > I understand one of the concerns for the async worker is CPU > accounting. If the concern is that the kworker's CPU usage is not > charged to the target cgroup, the userspace reclaimer could instead be > spawned with clone3(CLONE_INTO_CGROUP) so it runs inside the target > cgroup, and both its CPU and memory usage get charged there. > > One caveat: intermediate cgroups with the no-internal-process > constraint cannot take processes, so this would only work for leaf > cgroups. > > What do you think? I think all of this is possible without additional code and with this series. With AI, should be very easy to prototype it. Please take a stab and I will look into it as well (time permitting). Thanks for taking a look and also please let me know what other ways you think memcg can be customized through BPF in a beneficial way.