From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-66.mta0.migadu.com [91.218.175.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24F684749D6 for ; Fri, 21 Aug 2026 11:11:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787310665; cv=none; b=d2RIp2uGAPSQDUqSKCp3GD2R2evk/nZexKx9Ze6P8lyWgwfZIsW6naSd/05B0/RFtRzCXyt6wj2nBLbfX4yC0ebaMlbehLfyFI9KOrgWMWci246nFJWWj6PWlr6UuBxxzCCr7Jw1oQLO0AjswIAaMIZ+7HvZkxc+9gVbU9wbXrI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787310665; c=relaxed/simple; bh=mYT5UwAijBVrK97F80QgCk6yK1ol3oBU2yNff7Zom3U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=g90tosWAvy/LkhfhdJhVMpJ6Mm/zxzLyPjMXkmjBU29X5nDd/zCcbecSnES0bdUZXhuVYr2e381Uv6mIC0Qkx87gNSHAvVpg1M+YC3tWyHfHG5jwbeGQecaEQXJ9mKVjgiu3WuBPNwmAbKOj7ZpFmOiTAG1M7nQ1F/SH84QlB9k= 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=PweMOWrt; arc=none smtp.client-ip=91.218.175.66 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="PweMOWrt" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=mYT5UwAijBVrK97F80QgCk6yK1ol3oBU2yNff7Zom3U=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787310660; v=1; x=1787915460; b=PweMOWrtxn5pcuHfwUDRwK7ciSTQW157JD3/teCOC00jUPbK89UwrQ3SIBfbamaKb6mw5pXs UrR82rsqipW2eXj8fvwLVdAAJZBkxngCScpCTD5Skv1iuv2zs7XlcuBKX/gFAp7lWsazCGorqO8 ufe8+IT9R20Q2Kj4AWRFaeqQ= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [10.63.107.123] (14.29.108.92) by smtp.migadu.com with ESMTPS id 9025f6b9289340ee; Fri, 21 Aug 2026 11:10:50 +0000 X-Mizu-Trace-ID: 9025f6b9289340ee X-Migadu-Flow: FLOW_OUT Message-ID: Date: Fri, 21 Aug 2026 19:10:45 +0800 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: [RFC PATCH 0/4] mm/vmscan: honour node reclaim limits per type To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , David Hildenbrand , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen References: <20260821081741.1340277-1-ridong.chen@linux.dev> From: Ridong Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/21/2026 7:02 PM, Michal Hocko wrote: > On Fri 21-08-26 18:52:12, Ridong Chen wrote: >> >> >> On 8/21/2026 5:24 PM, Michal Hocko wrote: >>> On Fri 21-08-26 17:07:32, Ridong Chen wrote: >>>> >>>> >>>> On 8/21/2026 4:31 PM, Michal Hocko wrote: >>>>> On Fri 21-08-26 16:17:37, Ridong Chen wrote: >>>>>> From: Ridong Chen >>>>>> >>>>>> min_unmapped_pages and min_slab_pages are documented as per-type limits, >>>>>> but node reclaim treats them as one combined gate: once either is >>>>>> exceeded, shrink_node() reclaims slab, file and anon together and pushes >>>>>> the other type below its limit. Per-node proactive reclaim reuses the >>>>>> same gate and fares worse -- with page cache and slab both under their >>>>>> limits it reclaims nothing and returns -EAGAIN on an anon-heavy node [1]. >>>>>> >>>>>> This series gates each type separately via two scan_control flags >>>>>> (skip_slab_reclaim, skip_file_reclaim) set only on the node reclaim path, >>>>>> drops the combined gate, and extends node_reclaim()'s early bail to check >>>>>> anon. The flags default to zero, so kswapd, direct, memcg and drop_caches >>>>>> are unaffected. >>>>> >>>>> You are explaining what but missing the most important part _Why_ do we >>>>> need to have this addressed? Is this just addressing Sashiko review >>>>> refernced below? Is there any real usecase where the current behavior >>>>> matters? >>>>> >>>> >>>> Hi Michal, >>>> >>>> Thank you for your reply. I should have made the background much clearer. >>>> >>>> Yes, the original issue comes from Sashiko's review. Sashiko found that >>>> proactive reclaim fails to reclaim memory when the node's unmapped file or >>>> slab pages are below the minimum thresholds, even though there is plenty of >>>> anonymous memory available. >>>> >>>> After further discussion, we realized that min_unmapped_pages and >>>> min_slab_pages may not be used correctly. Apart from the issue above, there >>>> are other problems as mentioned by Barry in [2]: >>>> >>>> Even when page cache is below min_unmapped_pages, it may still be reclaimed >>>> as long as slab is sufficient. Similarly, slab may still be reclaimed even >>>> when it is below min_slab_pages. >>>> >>>> node_reclaim() cannot reclaim anonymous pages if both page cache and slab >>>> are below their respective thresholds, even when there is plenty of >>>> anonymous memory available. >>>> >>>> To address these issues, I am sending this series to facilitate discussion. >>>> Your feedback would be greatly appreciated. >>> >>> Those interfaces are relicts from the distant past same as the node >>> reclaim. I wouldn't bother fixing those unless there is a real usecase. >>> Pro-active per node reclaim is a different thing and we should probably >>> divorce it from those min_$foo counters altogether (if they are not >>> yet). >>> >> >> Yeah, proactive per-node reclaim currently does not divorce from those >> min_$foo counters. >> >> Did you mean that min_slab_pages and min_unmapped_pages should influence >> proactive per-node reclaim? > > Nope, exactly opposite > I would really appreciate it if you could clarify this further. Sorry, I'm not sure I fully understand what you meant. -- Best regards Ridong