From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (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 64E872C0F95 for ; Wed, 11 Mar 2026 17:00:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773248424; cv=none; b=Hq+hUXrAd/JRvOrgiORl85SH80uZU1wB/LjvCoE9yokXnWb9GWaxnFFSUGmiryMVuc+V2Jtf0ATfT7iXd38jcKGTiyvnzPyywcQD3CTijOgXzuV6enHuF+hZp25UcTsQXEqGHCmgVEX8UWR81oP0ZvUMSjjwfZbV1Btn0Ujmba8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773248424; c=relaxed/simple; bh=35TT/u99aRALHa0hnM2POym+gxT3aGGRaU/TmPXQhL8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PzIx/q+ya8VTROV1B6GNBsM08KuJ+Kv6SSeRJVmmuM+PHGcGWAnctIy3FgSn2MQ7EEFXsAiP5zvnyEPktlypL/LqNvuzSsoMWoIEEORqRO7ZrMaCI1mK0tHPfFS+WnfGcra4tWxfVYUB/wIJRd9hE0GELPjB6mtiFevL505pdKc= 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=pjqpT2QE; arc=none smtp.client-ip=91.218.175.181 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="pjqpT2QE" Date: Wed, 11 Mar 2026 10:00:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773248411; 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=8u7gOfH94HKLacZFGszI8Rx3/Wm+sBV0C+t5lK8/D3g=; b=pjqpT2QEx4QK4mt9WWipNl59lZpDJsmlzMJx2BS0z9m7lFDATjsn4sT7L1t5WG0S8BWeR7 30jtKuIoe2+ew2uhWL2YcasG+2v14BUqCRQ1kfYnUQH31uq5teDA8hxaVhrB9tOQ0locxG WlaeoTQ+EuQzlgyi0SYgYA6788FQ2UM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Jiayuan Chen Cc: lsf-pc@lists.linux-foundation.org, Andrew Morton , Tejun Heo , Michal Hocko , Johannes Weiner , Alexei Starovoitov , Michal =?utf-8?Q?Koutn=C3=BD?= , Roman Gushchin , Hui Zhu , JP Kobryn , Muchun Song , Geliang Tang , Sweet Tea Dorminy , Emil Tsalapatis , David Rientjes , Martin KaFai Lau , Meta kernel team , linux-mm@kvack.org, cgroups@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC] Reimagining Memory Cgroup (memcg_ext) Message-ID: References: <20260307182424.2889780-1-shakeel.butt@linux.dev> <6076b8c2-c198-442d-974f-b3084a0cd1b1@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=us-ascii Content-Disposition: inline In-Reply-To: <6076b8c2-c198-442d-974f-b3084a0cd1b1@linux.dev> X-Migadu-Flow: FLOW_OUT On Wed, Mar 11, 2026 at 12:57:34PM +0800, Jiayuan Chen wrote: > > On 3/8/26 2:24 AM, Shakeel Butt wrote: [...] > > > > Per-Memcg Background Reclaim > > > > In the new memcg world, with the goal of (mostly) eliminating direct synchronous > > reclaim for limit enforcement, provide per-memcg background reclaimers which can > > scale across CPUs with the allocation rate. > > This sounds like a very useful approach. I have a few questions I'm thinking > through: > > How would you approach implementing this background reclaim? I'm imagining > something like asynchronous memory.reclaim operations - is that in line > with your thinking? Yes something similar. I still need to figure out the details of the mechanism but it will be calling try_to_free_mem_cgroup_pages(). More specifically the context need more thought because we need to account the CPU consumption of those background reclaimers to corresponding cgroup. Will we be using BPF workqueues or something else, need more investigation. > > And regarding cold page identification - do you have a preferred approach? > I'm curious what the most practical way would be to accurately identify > which pages to reclaim. That's orthogonal and is the job of the reclaim mechanism which can traditional LRU or MGLRU. >