Hi Hui, Please narrow down your CC list, I would suggest to CC only memcg and bpf folks.
On Fri, Aug 07, 2026 at 03:01:49PM +0800, Hui Zhu wrote: > From: Hui Zhu <[email protected]> [...] First of all, good decision to decouple this series from the struct_ops for memcg as the struct_ops for cgroup series is still in flux and I have different plans on how memcg struct_ops should look like. We can discuss and collaborate on how that should look like which satisfies the real use-cases we have instead of arbitrary or imaginery use-cases. Others are already discussing the bpf side of things, so let me focus on the memcg side. > > +/** > + * bpf_try_to_free_mem_cgroup_pages - attempt to reclaim pages from > + * a memory cgroup > + * @memcg: the target memory cgroup to reclaim from > + * @nr_pages: the number of pages to reclaim > + * @gfp_mask: GFP flags controlling the reclaim behavior > + * @reclaim_options: bitmask of MEMCG_RECLAIM_* flags to tune > + * reclaim strategy > + * @swappiness: swappiness override value, or a sentinel to use > + * the default > + * > + * BPF-facing wrapper around try_to_free_mem_cgroup_pages() that > + * validates and translates the @swappiness argument before > + * delegating to the core reclaim path. > + * > + * The @swappiness parameter follows these semantics: > + * - Values in [MIN_SWAPPINESS, SWAPPINESS_ANON_ONLY] are passed > + * through as an explicit swappiness override. > + * - Values below MIN_SWAPPINESS are treated as "use the system > + * default"; the override pointer is set to NULL and the cgroup's > + * own swappiness setting takes effect. > + * - Values above SWAPPINESS_ANON_ONLY are rejected as invalid. > + * - If @reclaim_options does not include MEMCG_RECLAIM_PROACTIVE, > + * the @swappiness override is ignored entirely by the core > + * reclaim path and the system default is used regardless. > + * > + * Swap usage during reclaim is gated on @reclaim_options: swap is > + * considered only when MEMCG_RECLAIM_MAY_SWAP is set. Without this > + * flag, reclaim is restricted to file-backed pages regardless of the > + * @swappiness value or the cgroup's swappiness setting. > + * > + * Return: > + * The number of pages actually reclaimed on success, or 0 > + * if @swappiness exceeds SWAPPINESS_ANON_ONLY. > + */ > +__bpf_kfunc unsigned long > +bpf_try_to_free_mem_cgroup_pages(struct mem_cgroup *memcg, > + unsigned long nr_pages, > + gfp_t gfp_mask, > + unsigned int reclaim_options, > + int swappiness) > +{ > + int *swapiness_ptr; > + > + if (swappiness > SWAPPINESS_ANON_ONLY) > + return 0; > + else if (swappiness < MIN_SWAPPINESS) > + swapiness_ptr = NULL; > + else > + swapiness_ptr = &swappiness; > + > + return try_to_free_mem_cgroup_pages(memcg, nr_pages, gfp_mask, > + reclaim_options, swapiness_ptr); > +} This is just a wrapper on try_to_free_mem_cgroup_pages. We don't want that. At the moment try_to_free_mem_cgroup_pages is used by limit reclaims (memory and memsw, high) and proactive reclaim and has become a weird looking interface. We should not expose it as is to the bpf programs. Let's go back to the use-case for which you want to expose this interface. Your cover letter says proactive reclaim. Let's focus on (existing) proactive reclaim use-case (in future we may want more functionality). Proactive reclaim is done on a given memcg, amount of memory to reclaim and swappiness. Let's start with just: unsigned long bpf_proactive_reclaim(memcg, size); And if we clearly have a swappiness use-case then let's add one more kfunc: unsigned long bpf_proactive_reclaim_swappiness(memcg, size, swappiness); So, my main point is let's drive the kfuncs from the real use-cases. thanks, Shakeel
