From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (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 C24223AE6FC; Wed, 27 May 2026 09:31:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779874305; cv=none; b=sPKJSKZNIgunXorbQ+ALR7pKP2mfTLI/gMxGDekI/IWMnBvDCEO/gVi1+6sxnwmtqncBe4FPcJK31PJfg78Yk1yExXsRtc4oGK7nbAydf7k/C+wJwYVQ4oZ2lexfRFZrzoQHQgf7ANkWEqP/XAyfeqorQmSlipkeLsoE6xLl64o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779874305; c=relaxed/simple; bh=Ucv7tb+rmrQP+8WizGjWiU6fScLBdmJqqU5mtPvlgP4=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=i6x4WOJHKc+GCOsB6kiSyRn5PoKQ6A2MUx7OI6zyQ2E4QIIsFaeJtZ/ixlrmVBkKRK9ZAquofNf8ZvriDt7BonEHQ04z9KnwLWTC8fViStLWvrZtXaeIf7d7utb534pRRthAzag/2xsLtLl90GkiEyzXCWOKfTU2MDlfLcKSlpE= 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=fsjTDaB0; arc=none smtp.client-ip=91.218.175.179 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="fsjTDaB0" Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1779874291; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cuHmtgVXBwRM6gWFejLSgCD1TBA09WsjOdpw2obbiq8=; b=fsjTDaB0b5qte/WIAecQkAPIKuw6nVsSpbTIf+6BctJmOUjYfsumfoQYf78vDzLMK/tLkg sYJMZhqLPfJv6F3AW/vyoB54xZhJCtm5zSdmguKpEea7cU/8I/fEoI2pbaMG2IUuW4Eml/ Q0UQQ2PfILGhwbSHJD8pIjDYJGnG6cI= Date: Wed, 27 May 2026 09:31:25 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "teawater" Message-ID: <7f440116b23fba1e20fe70fda502ad66f7dbf158@linux.dev> TLS-Required: No Subject: Re: [RFC PATCH bpf-next v7 00/11] mm: BPF struct_ops for dynamic memory protection and async reclaim To: "Usama Arif" Cc: "Usama Arif" , "Daniel Borkmann" , "John Fastabend" , "Andrii Nakryiko" , "Martin KaFai Lau" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Johannes Weiner" , "Michal Hocko" , "Roman Gushchin" , "Shakeel Butt" , "Muchun Song" , "JP Kobryn" , "Andrew Morton" , "Shuah Khan" , davem@davemloft.net, "Jakub Kicinski" , "Jesper Dangaard Brouer" , "Stanislav Fomichev" , "KP Singh" , "Tao Chen" , "Mykyta Yatsenko" , "Leon Hwang" , "Anton Protopopov" , "Amery Hung" , "Tobias Klauser" , "Eyal Birger" , "Rong Tao" , "Hao Luo" , "Peter Zijlstra" , "Miguel Ojeda" , "Nathan Chancellor" , "Kees Cook" , "Tejun Heo" , "Jeff Xu" , mkoutny@suse.com, "Jan Hendrik Farr" , "Christian Brauner" , "Randy Dunlap" , "Brian Gerst" , "Masahiro Yamada" , "Willem de Bruijn" , "Jason Xing" , "Paul Chaignon" , "Chen Ridong" , "Lance Yang" , "Jiayuan Chen" , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, geliang@kernel.org, baohua@kernel.org, "Hui Zhu" In-Reply-To: <20260526134115.816081-1-usama.arif@linux.dev> References: <20260526134115.816081-1-usama.arif@linux.dev> X-Migadu-Flow: FLOW_OUT >=20 >=20On Tue, 26 May 2026 10:20:00 +0800 Hui Zhu wrote: >=20 >=20>=20 >=20> From: Hui Zhu > >=20=20 >=20> Overview: > > This series introduces BPF struct_ops support for the memory control= ler, > > enabling userspace BPF programs to implement custom, dynamic memory > > management policies per cgroup. The feature allows BPF programs to h= ook > > into the core reclaim and charge paths without requiring kernel > > modifications, providing a flexible alternative to static knobs such= as > > memory.low and memory.min. > >=20=20 >=20> The series enables two complementary use cases. > >=20=20 ... ... ... >=20>=20=20 >=20> Asynchronous proactive reclaim: the memcg_charged and memcg_unchar= ged > > hooks, combined with the BPF workqueue mechanism and the new > > bpf_try_to_free_mem_cgroup_pages() kfunc, enable BPF programs to per= form > > proactive background reclaim without blocking the charge path. The > > pattern works as follows: the memcg_charged callback tracks accumula= ted > > memory usage; when usage crosses a configurable threshold, it enqueu= es an > > asynchronous work item via bpf_wq_start() and returns immediately wi= thout > > throttling the charging task. The workqueue callback then invokes > > bpf_try_to_free_mem_cgroup_pages() to reclaim pages from the target > > cgroup; if usage remains elevated after reclaim, the callback re-enq= ueues > > itself to continue. This allows a BPF program to keep a cgroup's > > footprint below its hard limit (memory.max) entirely in the backgrou= nd, > > avoiding the OOM killer or direct-reclaim stalls that would otherwis= e > > occur. The selftest for this feature (patch 10/11) validates the > > mechanism concretely: a workload that writes and mmaps a 64 MB file = inside > > a 32 MB cgroup reliably triggers memory.events "max" events without = BPF; > > with the async reclaim program attached, the "max" counter does not > > increase at all across the same workload. > >=20 >=20Hi Hui, >=20 >=20Thanks for the series. > Would it not be simpler to just have another memcg knob, something like > memory.high_async. > When memory usage > memory.high_async, queue a per-memcg work item that= calls > try_to_free_mem_cgroup_pages() until usage drops back below some thresh= old. > I am not sure I see what programability aspect from bpf you need here. >=20 >=20Thanks Hi Usama, That's a good question. By introducing a new BPF kfunc bpf_try_to_free_mem_cgroup_pages, a BPF program can flexibly control when to start and stop async reclaim, rather than being constrained to trigger and stop based solely on memcg usage or one or two fixed events, as with traditional proactive reclaim interfaces. For example, async reclaim could be triggered based on PSI, or on the number of page faults, or even on a combination of multiple events working together to decide both when to start and when to stop async reclaim. That is the motivation behind adding the BPF kfunc bpf_try_to_free_mem_cgroup_pages in this patch set. I admit the cover letter did not explain this well enough, and the example code does not demonstrate this use case either. I will address both in the next version. Best, Hui >=20 >=20>=20 >=20> 08/11 selftests/bpf: Add tests for memcg_bpf_ops > > Adds prog_tests/memcg_ops.c covering three scenarios: > > memcg_charged-only throttling, below_low + memcg_charged > > interaction, and below_min + memcg_charged interaction. A > > tracepoint on memcg:count_memcg_events (PGFAULT) is used to > > detect memory pressure and trigger hooks accordingly. ... ... ... > > --=20 >=20> 2.43.0 > > >