From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (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 394ED3D5237 for ; Fri, 21 Aug 2026 09:24:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787304306; cv=none; b=kZJ46ZjxHcpwUgf0Jq2AjaCvYRac8daiUo47x4VC9JsJGvJUpCMIXyM1TCbjwvWHqD70OgKG9qsvceER2HQz2Ko9KAqOz45oM+ADdbbnRVrmsqY68YQ1XpEw2vGFijhK5JoKDsmBpVLBrh2VsWJ3c+StujMd4CyaCQXJSOkhdaE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787304306; c=relaxed/simple; bh=i4Y7Xzd1iqdBSMCuJgi58rEY6+ZF0RwpsRYmwVYlesI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cJdd2zzP93q2uqbVWzMHJi+wC8APFflqTUFC9g1yLPw3gozXba1lSBJotjRO+hrlVoQLrdKj9Cw1jcX1WOFZiUQc788kFJU+XEP9WIeR+DGXRkDNhfniF/iET2w8QNLs6kQgWuUa59W8DN3DPmYjDwtBTcskHkSIgCWgQuO3Jt8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=HYYFHWFV; arc=none smtp.client-ip=209.85.208.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="HYYFHWFV" Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-6a0a4a28cbdso1561275a12.3 for ; Fri, 21 Aug 2026 02:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787304295; x=1787909095; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=xrvJ8t01wSuPVhMK2rhUOR81NuGr3NcfrpigUqOVjnE=; b=HYYFHWFV/K8JKn4AFlgsrdMBZeI39+R2pRYVCnGbp8+Jf6vBkDJwlE0xi0nJcGL/AB YiWsYUI1KFl7xpBygiwv7P+1m4m7Yx4wX+Qb/3kuEnFljQIMLA6x1ni6YdzfzpRbJmtf a2JK4Tdjilyx7e1Az+MiP2d31BcJHWkVn1xj6ysYx2csVWJgf5iIvBY5iBXdOR0WvbnU 6+gqcURbpK48v5o2rY13zfxf097XE/E4Fdgt0Le5fcLKa+hKW9LpJLw5bClvP2rUGOZJ JrYQqhz07MQ9GF+Jlyeit0ETynJ2o3fzekXifeqX1wVn9ecSCMHO1Ksx6ycHyyoYNhpt Vu6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787304295; x=1787909095; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=xrvJ8t01wSuPVhMK2rhUOR81NuGr3NcfrpigUqOVjnE=; b=Sa3mh0usPSUjlfxUlNU1/ozPgOUvpj2+14FkMZlMIuKNNf5fJmXpNzcLbbJaAoV5ne Ahr9V6pjMrK1F16tPNPEG8XauObwBWlohYNA6MQ5YAWnBG5DZeOhLlRP/p3YaJt2OuQ1 dnQchpVw2soRE+MO7yY5+f7eY3vVER9nVREJDDxIUHFmyXVK3xWHFSh3zYOoLieqhrjJ ovn0YRfzLkLBUjZA8lwuWzjwxJqQUx6iK0VtxaDlF7vVHuULqYmTZSC9ajYvkHXiGtLs B+fvk5HLr/kwMl7RsaqYPmZDK8Ppe35Nk8M72B0N3BpdmYglogrVbs8vKL6VGtVVTgP6 hMhQ== X-Forwarded-Encrypted: i=1; AHgh+RrdxndmLHi0dWFKg5yLnhr59NlIGCZHvo92zvLjGAjKSpwFdMDW9PA6oeM9uohJVkl7f1M5kdRFk8rVWA8=@vger.kernel.org X-Gm-Message-State: AFuF++k2Bt08aU41oLGurw+Ttz8tLC6igHRziiFJPzKSxd02zHmG79mx HBLNIewlWxRkZMAmqFnJg3i1Ao1QEHPKngpkyVPGzTBVIgcHi+10g5akHMG48d8TIn0= X-Gm-Gg: AR+sD13pgTt3Y9bLRq0aBee4f0LWqNL//Ogoy5uhPZdl2qHq90N6vNVYvb6CeGkFuaR rn30xD3wqWfyYvhCLdkw62ABA7U19OV7YN6xQ7zeSdWc1h33IyCI8ZUCx0EUI1PGarbOxx8tHgr aNStJvosfmnx4M+Vv+963bOuG2sT21VeGnM8+KL/VP3pEyjJaokQfMm7LEwbIWkhUeYJ+bTicxp kzHtiv7+6xo0aMnCkSH0AikLn+5j2Bk3AQoJIraFk0NcAPEQgZbLXFvQjT6xlquYd9edMQCko8D WEKDF5SbF17lxeppuT4U/5l22ASmr06RBjUo7DjrwoyaCYsJjRxY6jCxJeTungzaKfPcApoWzOe uAXGsUC4CwoedPmBOKIM3m+/z8ueyPkaFd+omiWBbdYrbAzE70Y5yORtCW3t8PmfJVg2hbZEVfK c0Lf96U3x0eFsEi0dy8TkQBn294zk+Q674ofw3yOzREzev9tmK8YWCewo/ro9KodOfrUCacmk5j kMgityOSaxV X-Received: by 2002:a17:907:9495:b0:c24:7cb5:d617 with SMTP id a640c23a62f3a-c247cb5d969mr246787766b.1.1787304295516; Fri, 21 Aug 2026 02:24:55 -0700 (PDT) Received: from localhost (109-81-81-112.rct.o2.cz. [109.81.81.112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24591e037dsm385915066b.52.2026.08.21.02.24.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 02:24:55 -0700 (PDT) Date: Fri, 21 Aug 2026 11:24:54 +0200 From: Michal Hocko To: Ridong Chen 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 Subject: Re: [RFC PATCH 0/4] mm/vmscan: honour node reclaim limits per type Message-ID: References: <20260821081741.1340277-1-ridong.chen@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: 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). 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. -- Michal Hocko SUSE Labs