From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.45 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793183257; b=ZGUAIBASedpwyYKgPTfi9Kqz+D5EvL0SjSuSm2KYHbHNepNcdAo6eetTcfUCMQsWDlN7 vAAAJYw1XKqH+imkf/WRuI+bin+3Ng3A/1L4auovr3hndRk8QjeYtPf9v/aiDNBwKP+cf z0xg2kMxYFTfMHH5PzzqlzaVYRS4PzxxrOtQBGGh5YEGHr3GT/6EXd/ickvLTFphq0D9n TyhnoolfSi+AOzB0yI253hdzfaYuAZY5SWIrJnFaRtFBATFe29OE3TCO5nk0PqBy/QL5/ mZUgf7nRIx8dilA5lnJc6Tp+hcSoaXnRycXnMXPAMBE6BYs6oG7hlvUaVPjthAy4hWQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793183257; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:MIME-Version:Date:Content-Type: Content-Transfer-Encoding:From:Message-ID:TLS-Required:Subject:To:Cc: In-Reply-To:References; bh=CAsQNlvEQewVVFce1WqlpSDwej6JOKTiJP6Vd2oTTAg=; b=Da4vV7X4jI9qxCqgudrvsWVoVCJO7t2XrGL0h+3VNlOWOMbMHc8JrUXrKjDb6SHS8GV4 2bBTn3XIySz6LfhgsPWOqumVt2GYZlQnPzAB04qC+ePI9B/2OZo1r8kqu6wHcVJQQ2b2u 9WKdnQKfFCvGdNHZipsmVDOsYKZbewiw++VUo4x0QfPOyz2ctbDVcaq31BiHBCqrPymTJ EmXQBFTzA7CBkVBRHnvjp+p+pRI3aZ2R+9MZDBtSorhqFw1IP5vqsBW3xPNCNqoJSR2yc +arASBOD7mpi1uhcBN5p1UMO0d/sG+H8tQH6fE6eZMCrGDdmygmxypxAooiJC1AExqw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b="Jmwex/kK"; arc=none smtp.remote-ip=95.215.58.45 Received: from mta1.migadu.com (out-45.mta1.migadu.com [95.215.58.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93FE0606A31E for ; Wed, 28 Oct 2026 10:27:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 93FE0606A31E 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, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=Jmwex/kK X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=OSNgAFP+VgQv9q7o9VlptAb+MUtYzG3jKiN7D8DtKj8=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793183254; v=1; x=1793788054; b=Jmwex/kK7FpuCV4bqSsS5FCwcMt+EqZgDLePJZ4dvcrpEr4L/YHoyx7QKjmO1CIocO5OCbGr tkZmoFbOPWPIzOshnL3/DpTiXzlghHbrudm38WhVc3KkL5yD0mKtIroNlIaYfbth6p94x+Qcx/Q vj7/M3C4X89z4qZWGeENzS/M= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id ee56cd7c32368443; Wed, 28 Oct 2026 10:27:33 +0000 X-Mizu-Trace-ID: ee56cd7c32368443 X-Migadu-Flow: FLOW_OUT X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Date: Wed, 28 Oct 2026 10:27:33 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Hui Zhu" Message-ID: TLS-Required: No Subject: Re: [RFC PATCH 0/2] memcg_ext: dynamic memory.low and memory.min protection To: "Tejun Heo" Cc: "Alexei Starovoitov" , "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" , "Jeff Xu" , mkoutny@suse.com, "Jan Hendrik Farr" , "Christian Brauner" , "Randy Dunlap" , "Brian Gerst" , "Masahiro Yamada" , "Willem de Bruijn" , "Jason Xing" , "Paul Chaignon" , "Lance Yang" , "Jiayuan Chen" , "Emil Tsalapatis" , "Ihor Solodrai" , "Barry Song" , "Geliang Tang" , 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, "Hui Zhu" In-Reply-To: <769e80ffa618327ac03c13c4657e7229@kernel.org> References: <769e80ffa618327ac03c13c4657e7229@kernel.org> "Tejun Heo" : >=20 >=20Hello, Hui. >=20 >=20On Tue, Oct 27, 2026 at 05:11:58PM +0800, Hui Zhu wrote: >=20 >=20>=20 >=20> Why it matters: memory.low and memory.min protect a cgroup by a fix= ed > > threshold and have no idea whether it is using the memory. A > > high-priority cgroup that holds a large working set and then goes id= le > > keeps suppressing reclaim on its siblings, and that memory is wasted= . > > A policy program sees the real activity - page faults, charges - and > > can grant or withdraw protection as it changes. > >=20 >=20This doesn't justify the changes. Why can't the same be achieved by > adjusting memory.low and memory.min from userspace? The arguments made > so far are neither convincing nor proven. >=20 >=20Thanks. >=20 >=20-- > tejun > Hi Tejun, Thanks for taking a look. You are right about that paragraph. It describes what dynamic protection does rather than saying why it has to happen in the kernel, and at the timescale I described a userspace agent writing memory.low would keep up fine. I will drop it. Let me try to say what I was reaching for, from the code rather than from a benchmark - a comparison between BPF and a userspace agent would say at least as much about how well I wrote the agent as about the interface, so I am not sure it would settle much. memory.low is a request, and what reclaim honors is elow, which page_counter_calculate_protection() derives on each pass from the parent's elow, the siblings' requests and the tree's usage. At the first level below the reclaim root that comes out equal to what was written, and there the knob is enough. Deeper down it is capped by the parent's budget and shared out between siblings according to what they claimed and what they use, so what a cgroup wrote and what it ends up with can differ. As far as I can tell none of that is visible from userspace: memory.low reads back the declared value, and I could not find anything that exports elow. Exporting elow would not help, because elow is not a property of the cgroup alone. It depends on the reclaim root as well, which is why page_counter_calculate_protection() warns that it is not stateless and is only valid as part of a top-down tree iteration, and why mem_cgroup_protection() carries the example of a concurrent global and targeted reclaim driving a child's elow to zero. A file would show whichever value the last reclaim happened to leave there. So the derived value seems to be usable only where it is derived, inside the check, and that is where low_policy() sits: it is evaluated per pass and is handed that pass's own inputs - the memcg, the reclaim target, the elow just computed, the usage - instead of being state that is read at the check. The other half is what a policy can key on. memory.low has one dimension, bytes. A policy program is not limited to the ctx it is handed; it can also use state that other BPF programs keep, so protection can be a function of activity rather than of size - a workingset refault rate, for instance. [1] reads those counters from BPF and acts on them; it drives reclaim rather than answering a protection hook, but the signal it reads is the one such a policy would want. The limit is on the output rather than the input: the hook returns a boolean, so it cannot grant anything memory.low cannot. I would be interested in how you see this - in particular whether the nested case is worth supporting at all, and if it is, whether this is the right shape for it. I am happy to rework the patches, and to add a demonstration of one concrete policy if that would make it easier to judge. [1] https://github.com/teawater/memcg-async-reclaim/tree/memcg_ext_plus Thanks, Hui