From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (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 07E603AFCE2 for ; Fri, 21 Aug 2026 11:02:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787310167; cv=none; b=XX62hRsNMy31ze0D4Li7gWC1lORRfSwig8SlyspiQG4u58ZDoj6+ZnxVuKiuRBwPC+BH8hD/6kEwDUa0U/2qMiWLxRgidGjqHLVSqDRqvT/gud0JOsaDSlM32Ii+LZWWbd2MOSzUVBVBzVqo1sB7GRdNWbZcEouvk4Ame4FXEcA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787310167; c=relaxed/simple; bh=JFlUENgK+e2rVNDoBcAi7ohnf/qzlSzapghIIx+lJdM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HVPElvfjbLQzaxwDcZMn4xB24A7gkzeag4kK28KCk5+qRewTz9y/6oFso4aPQA1q+Xo3d54C5PA/td/AKUrsN8i6V2qpx/Tc/py9tDGzM/fV6QTnj8k3SlTzCgfkpWWbEONsIgXGmkRvmB3ZvaK8L5wkYqFo2DEXuzdfiam6K5Q= 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=FXY2GLfo; arc=none smtp.client-ip=209.85.218.44 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="FXY2GLfo" Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-c2074710751so158554666b.1 for ; Fri, 21 Aug 2026 04:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787310163; x=1787914963; 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=X+Zbs7AKbQaKbIL7murYn+4F5I2qORmS8p5vc7CpbKM=; b=FXY2GLfoIMocXoUrN3GJ9bxMFWxbUxSC3PKHQ11chVV5q346NDCTwxSAdz7Ld1/3AB equfQsZ7mNAYDP5qWOR3rR62ceeMW6E0oH+RupSXsfLJkoSBHu8HQ+bRtG3CF9TfYVtB WIEpLpoIBvRZxBCkTNPH6dUNrQb3FJySJNLpz/QwaAbwmnH08sJGk/6A4+wLj6KQpSpx ogbmHzdq+Vfmq/df5hcwdFAKo3qdkk2urDpMbyxsu54YmI5vC+fU/Of+Ndm6+iTHLA13 pqPVOBIPXmkEQIjVB4ZVh4cDf4glCCCROlwnK2I/9FAxn1wuss8qg38PxWrIzxq3jUZU a+9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787310163; x=1787914963; 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=X+Zbs7AKbQaKbIL7murYn+4F5I2qORmS8p5vc7CpbKM=; b=i/OmjoLb6rXaUtx+Yywq744+kPJ8mBqX/qMSRdN3ALbVRKtZq2jzyY6zo1Iqm3+56H qxOhnNdm5TkXidEt+++quKB9L1NBygKbDJkE8oqf5k9hCxaLVI+97bs5bXOFlEfdM2IF jMsjizPW/VWxg/8mLeut9N4VgKR6Cp54dYTD3vPj5a9GZobtZhTkSUSw6gxhjY1+AFGm 0+NrSBHedtwPJVOdzS+kq04Nln1BeYj+s70kMIii7toeUSYtEOuOJgrvND+PdzqsPH1F KGZvzkiWuMV+wivs9vdIyKKLz8SuSyiK7xjo+2J/uTzP5UED/F0QUhd2384BYU1Hg9jh MSHA== X-Forwarded-Encrypted: i=1; AHgh+Rrjzr9uge1kFG+C4uJN7zzIda0N9VjNOqABlyqtd7uvrKIz40U3SzmntUKQB0lwGQSDuVcKYBki2R61yvE=@vger.kernel.org X-Gm-Message-State: AFuF++kRmGeZk2VOXO1qjQUwvmpy4/tdBV0ppYHGAwhmfG4w4c4YuNo5 c+a3y2yGJS7WFiScjl80rUpp/KDmjZUJPW96K3u5UbofNYv9WKT/FXQE/avMteqp/JY= X-Gm-Gg: AR+sD12KSLyNt7PpHkCCxwTrh0NxIrVKKMJxFdY3NoAZZAXZPVlCgJ4Py7jfB/Pi6OJ FcqMXq6t2jyIcuYXqVahbBIJLxZoMylJfvUaNGr3HhOpQPSsKqNZnsdIH86GT7udSIRRfADtiJP 3kj445iYv3bmOE7rwpbnPeaBXL2WrtAx0/zoIn+qflbYIFqbYZmP75JfB5ZrO9kgZjk7VfzAKNS FrQz+zIclQrPZies5oI2EhBILIurYdD7EDM1TSIjJRP4TRjYp86/NqDxPm4FCSvkUqgA6jnYItZ 7+amm07Ak46KVA6M3Q8tWaQl37eSIbEPZoNtj5CCdYo3c3iAqhI4C006unozSGduxSTtTgGLYQs RLj0NN6ZLCsikGaxfaComB7JUN2S1QKaOuq98wUQtmsDdDOGEnkyzx6TnF2scUdQxByxbCLuMkq mhKoXctFGflapGOBhKPxjCXEXr5RTPPuzuTs+XoAhasEsuWwVVp+W6Swzg72n0bvwb93BEx1cmx A== X-Received: by 2002:a17:906:f5a6:b0:c24:87e3:b8b8 with SMTP id a640c23a62f3a-c2487e3d755mr132843366b.17.1787310162979; Fri, 21 Aug 2026 04:02:42 -0700 (PDT) Received: from localhost (109-81-81-112.rct.o2.cz. [109.81.81.112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c2458b58a50sm456168766b.26.2026.08.21.04.02.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 04:02:42 -0700 (PDT) Date: Fri, 21 Aug 2026 13:02:41 +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 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 -- Michal Hocko SUSE Labs