From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-38.mta0.migadu.com [91.218.175.38]) (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 6A7BC432BD9 for ; Fri, 21 Aug 2026 10:52:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.38 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787309549; cv=none; b=Gd+60n2U5K8xuUDAW0G3UdKRLD2Y31PFsLL4+6PZ5sdkHOKhEXlFKChUOHbWVAaP5IWD6iD3vJ9P6qGE8+f8LiHaIxSqMz3qQr5xQ1IzFO/jKR5XkAoTsdvvOZHG1tF89jj7PjbFm0zDTt5m4AE8GEg1b5catkPenCP6q9tkkko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787309549; c=relaxed/simple; bh=OJ4pxc/BY65f+YEdniNKvlySGT/ge79fTwWc2GA2zdM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rxUY6byemVptwYhl7NaDyqs+rhsJ2Rs4HqN9//vREdL5cVtTkNg5cpg98yMRqMiZbv4Y2RVNgqf1GqlasJHTr3gzTR8oUeIVQdalPJuT+Om3B6PhM2XaQxsKL8advF007+1C3ChkeM0VOwDf5o2I5UcFMygu8bIT3gegd20rGsI= 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=YnpO4Omu; arc=none smtp.client-ip=91.218.175.38 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="YnpO4Omu" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=OJ4pxc/BY65f+YEdniNKvlySGT/ge79fTwWc2GA2zdM=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787309543; v=1; x=1787914343; b=YnpO4OmuH0tFHOshJVDhjjNyRj1oLTMLHtrVvOOxQt43gYQXbtZEBCnXZc+y4Wi5KWW0E6sU 5QRqTMt/enjXvh0w7ubtwPuNLbknDLwpRuEecmsbo5ruLE2oKIHKwTjLoTwvsoEtRmwWuea0N6d ZSkZCcdPPz9LOFSkYCEYF2fM= 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 926e7f4a7c17a838; Fri, 21 Aug 2026 10:52:23 +0000 X-Mizu-Trace-ID: 926e7f4a7c17a838 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Fri, 21 Aug 2026 18:52:12 +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 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? If so, perhaps the easiest fix would be something like this: ``` static unsigned long __node_reclaim(struct pglist_data *pgdat, unsigned long nr_pages, struct scan_control *sc) { ... if (sc->proactive || node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages || node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > pgdat->min_slab_pages) { do { shrink_node(pgdat, sc); } while (sc->nr_reclaimed < nr_pages && --sc->priority >= 0); } ... } ``` > Same as checkpatch.pl, shashiko is giving you hints and you shouldn't > simply follow them without a deeper considerations. Consider that there > is review capacity required for any patch posted. We do not want to > waste that scarce resource. > You are right. I should be more considerate. Sometimes, due to my lack of experience, I cannot come up with a good solution on my own, so I send RFCs to gather professional opinions. Thank you for your time and guidance. -- Best regards Ridong