From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 0BC7323D7DF for ; Tue, 14 Apr 2026 21:38:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.135.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776202686; cv=none; b=tLzrCh3CynYbQgpVO3Hbxf3qPSAl0B5uk5iohtcu75KBlMls6SxrguYJQjYRtBCpzmq/FNnNbE8TOXlAktlPc0mR7DxlyLpwAefC2bU10SU+MOHSXGUDOq9AGBP3wT9seZIc3T6/dA0hV0/SKrF17KjnXGCzIk/EtwQrrVzKzVk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776202686; c=relaxed/simple; bh=DEFSS2q02pWP6UUYlrxXuu9KfDptScqFb1kgIJb/BJg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jgrVGFtGKenzBgGCdwDOs1Ar2Ag7kvY1Nwxtpa9XiUv+Q8UI9MCWN15e0gHTlodwsX0gksIhGMmpOP43JhO/hWL58yuql94lXORsRt4hqL7q1ryfQxtw4hsQRnv0jO8fcjvGaBAXG4tJ0e/5l9pTMYstZ5u0DUDoY6OBcK/GseQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=columbia.edu; spf=pass smtp.mailfrom=columbia.edu; dkim=pass (2048-bit key) header.d=columbia.edu header.i=@columbia.edu header.b=UenZrEk4; arc=none smtp.client-ip=148.163.135.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=columbia.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=columbia.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=columbia.edu header.i=@columbia.edu header.b="UenZrEk4" Received: from pps.filterd (m0167071.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 63ELR4Ym2765347 for ; Tue, 14 Apr 2026 17:38:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pps01; bh=OB6p idPOLogYNyD7EEIfdqKqbTJQgvZ9at6gZ/qm2j0=; b=UenZrEk46SZcHtFJ+Nb/ fAr5m0bGK1fniVV7xmiFAY040zcT8vaHuwvuxVxJrMYbQ/zsRlyiKAxBEhoVHg0o 6qwwUwYgH1AfiKYfzAnxuDCVaYVjtRtWW70Z+A4DcgesmW1x7yjUeBzDwCG+PlnN CwvWMCtVMNCc4LTK/Nr7dsBDSjiv43QXfAn+lmv02jmXdearK6k9/eFjW5J2slFu H4AwoG6CxV0JL4H8uDkYl61V+5TT1hbMUaz2d2SMV96nL7O9UVaQXJGGDrwa8eHw wQoPgrbOctjF9NwG/8osy/tOG/ldJv+/bMH0NL+ep2pzoH0QgHPCwIbWMMGZVtDY 0A== Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by mx0a-00364e01.pphosted.com (PPS) with ESMTPS id 4dh85drkds-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 14 Apr 2026 17:38:04 -0400 (EDT) Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-8aca3b7b536so80586626d6.3 for ; Tue, 14 Apr 2026 14:38:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776202683; x=1776807483; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OB6pidPOLogYNyD7EEIfdqKqbTJQgvZ9at6gZ/qm2j0=; b=hW0dZHlEI9TL0TnOe99tdD70PiIQekBTEEL9S/5YjIs1fJ452wMZRiadQgNCyMUu6e gP6UKEQs5rT5GWb7exfrAKKeqHrzzPF36L0M+wxqpRZ/VFmDvI09OVFHhnmnt8SMMWIQ PA+DVSyqHbhq8E9U2k/PPt0SkI1tlfKC9pX5NTjgz8WRMmO70BaREjGMwZarhmPLYRTj oD+TXkgEaW1WXacb2vgIh/Q+ZeZjx38Wshaku4ckI+bU0LDVI+4O1hpMgcQ7hkFTkELw a7FfwZjOTHuIJjjM5Jy/3RtmQMPPlVvtcbs4zeVVDf9Xlsez29YmlDW4sTvaDhB19qQr KM9A== X-Forwarded-Encrypted: i=1; AFNElJ9Nnk6O8KC5azWKbR4TjJ4ES/evdkYJ+CPgEDvwDKpaXH4HO3+xg9kPgJjP8wEeC5YyA9BHn04sxXIJ6GY=@vger.kernel.org X-Gm-Message-State: AOJu0YyyGAYxDCYj7GlgfU2mDQRbEc0B70NY906xC+GrFHIxh1CmIa+c w+JqqmrfOKHV8Q/4Ao2cOWH6WNYlyvAGhL8cJqHysuOWbIhyV0gh8i8W+6mDDy2pbIMjLr/a+cU jcIZyijL7+SGrAS5Ildr9tDI3dk5EQAZO6wJoioA2PlQAmMaCnBQ2U4vWKl0btQ== X-Gm-Gg: AeBDievEdcT3cnj/MDaAKEzfh9VaxS0WVztSb6nn3kuMUZBMLzxgZ5JJM1wt6ZYXM5M OvroZrrqxCEmPFVZ1BD7dBKoUCNBoQwKChDCk32KgjgA1aIzcdS9sqmhEzJnfdX9N76pD4In1no ZDA/OH928bSYM3cZWyogXTfQFxEG4+q7HDUZU/n952UfOe+wdUvaP7ZV51LAVMa1jTzc9dE1LNE WEt6nUShjXcH450aZpejnjNrYEAcJHj1335yOGCsZzL4KWSS62+DU9yf8QWRgRKb+M9AuKt76j1 9vnqYr1FdEa0P6voUQYPjfl8rWr2h6tfcPwlnxBpAYyX3igd2LvedOUyCE8fISK7KPp5awaYZ62 dCzdhS241JvshhbkwlyILotNHZbU/JGQ8roYX3hflLOzAQTYRg1xOyneNSbg862w6n6/5iwI= X-Received: by 2002:a05:6214:4905:b0:89a:1364:1027 with SMTP id 6a1803df08f44-8ac8617efafmr306359456d6.14.1776202683050; Tue, 14 Apr 2026 14:38:03 -0700 (PDT) X-Received: by 2002:a05:6214:4905:b0:89a:1364:1027 with SMTP id 6a1803df08f44-8ac8617efafmr306358966d6.14.1776202682633; Tue, 14 Apr 2026 14:38:02 -0700 (PDT) Received: from [192.168.1.62] (dyn-160-39-33-242.dyn.columbia.edu. [160.39.33.242]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ac84cb0474sm132012676d6.40.2026.04.14.14.38.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2026 14:38:02 -0700 (PDT) Message-ID: <5c1205ec-cbcc-4976-85d3-0643083bfbba@columbia.edu> Date: Tue, 14 Apr 2026 17:38:00 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext) To: Lorenzo Stoakes , John Hubbard Cc: Matthew Wilcox , Axel Rasmussen , Gregory Price , Michal Hocko , Andrew Morton , Shakeel Butt , lsf-pc@lists.linux-foundation.org, Johannes Weiner , David Hildenbrand , Qi Zheng , Chen Ridong , Emil Tsalapatis , Alexei Starovoitov , Yuanchu Xie , Wei Xu , Kairui Song , Nhat Pham , Barry Song <21cnbao@gmail.com>, David Stevens , Vernon Yang , David Rientjes , Kalesh Singh , wangzicheng , "T . J . Mercier" , Baolin Wang , Suren Baghdasaryan , Meta kernel team , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260325210637.3704220-1-shakeel.butt@linux.dev> <20260325190547.abb7309fb63473b57b7a90a0@linux-foundation.org> <6f40c513-af3e-45b6-9000-c61494a23bd3@columbia.edu> <70fd648a-efa1-465a-8e6a-51411dfd50b8@nvidia.com> Content-Language: en-US From: Tal Zussman In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDE0MDIwMSBTYWx0ZWRfXxDKuyI1AO0n3 qbbWcfqeY/VcOBMmJH08/xCIy4P0IJOCjwfcng2T2HS3DiZCjwgA0bTQRqLouo97G3vg5z5SCMC mDVZRDlm8LiXjP69BVVu0c0s40fh/1/U5gflaT/HS918/G7djWu+I76bTOCBRhOEhQKb27NQdlF v2ms2EpMvyAZZplF7iZpO8cPot1UIkVOC9L2HLNfpG19QG3CwefS5Efbp9coswULeAltFSs7vZ/ R9LIYkPm/+jky1zuDBaxT5GXQ8CBJgeXG8MbBA9snID6QXhYgg1H4Hm4XJDDbQMR6vZKBjcuafp uglnhwqspd5qwW9UzqHM4zWbGMQ1BMuecIoafPulw1BXhLE844JG1dN3Al3ZJkKPg3zG/So8cl9 UYoyAz/wXp+bj0I8n8UboHdbiX2/EmOV+/bXL61Rs4YDut6Roiv4Tx4Mcwx8h9x48QXAMf1f0HQ isuEX5o/g/pAlarj6hA== X-Proofpoint-ORIG-GUID: XOL5l9u_V4CuorbZDi4VvtFmk2hs4pd9 X-Authority-Analysis: v=2.4 cv=eJYjSnp1 c=1 sm=1 tr=0 ts=69deb3bc cx=c_pps a=7E5Bxpl4vBhpaufnMqZlrw==:117 a=GaPK54s0Se3oFqK5NkZy0g==:17 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=x7bEGLp0ZPQA:10 a=VkNPw1HP01LnGYTKEx00:22 a=Da8U98TiO7q1upZEImrf:22 a=79PYxaXUQd1wl-QFWJnA:22 a=eZBIlsz9hca5io5qbP0A:9 a=QEXdDO2ut3YA:10 a=pJ04lnu7RYOZP9TFuWaZ:22 X-Proofpoint-GUID: XOL5l9u_V4CuorbZDi4VvtFmk2hs4pd9 X-Proofpoint-Virus-Version: vendor=nai engine=6800 definitions=11759 signatures=596818 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 priorityscore=1501 suspectscore=0 lowpriorityscore=10 phishscore=0 bulkscore=10 malwarescore=0 adultscore=0 impostorscore=10 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2604070000 definitions=main-2604140201 On 4/9/26 4:22 AM, Lorenzo Stoakes wrote: > Yes, thanks for that, it's interesting! > > But I would say for now we need to defer any consideration of bpf being a > thing until we actually get things into shape in terms of improving and > modularising the existing reclaim mechanisms. > > mm has been far too keen to take features without paying down technical > debt first and it's been very costly, so before anything else, we must > ensure that reclaim is both long-term maintainable and maintained. > Completely agreed that cleanup is necessary and modularization is a big step towards that. I do think it makes sense to think about what eBPF would look like as part of that future though. It would be a shame to do all of that modularization work, then decide to integrate eBPF later on and realize that we need major changes to make that happen (but, given a well-designed interface, I think that's unlikely to be a significant issue). > In terms of reclaim bpf as a concept in general - reclaim is so very > sensitive to even minor changes, and I fear that people might find > something that appears to dramatically improve matters in one scenario, but > end up with an unusable system in another. That concern is precisely why we implemented per-cgroup policies. We found that running each application with a policy that works best for it yielded greater overall performance. System-wide policies may need something more generic, but if you can make them more granular, you can specialize more without running into such issues. This was simple enough to do given that the LRU lists are already per-memcg, and eBPF (is about to) support per-cgroup struct_ops programs. > A bad sched_ext implementation might result in poor responsiveness, but a > bad reclaim_ext implementation might result in a soft-locked system, and I > fear that it might be quite easy to do that. Anecdotally, having implemented about a dozen policies across dozens of workloads, we never ran into a soft-lockup. That's not a guarantee that it can't happen, but with a properly implemented fallback/watchdog to ensure that pages actually get reclaimed as necessary, this should be manageable. sched_ext actually implements such a watchdog to kick out misbehaving eBPF schedulers. > In any case, we can look at all that once we are in a better place with > reclaim, which Shakeel's proposal focuses on and I'm very much in favour > of! :) > > Cheers, Lorenzo >