From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-243.mta0.migadu.com [91.218.175.243]) (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 5E4573043DC for ; Fri, 14 Aug 2026 02:37:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.243 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786675082; cv=none; b=lpfPj3OxozoES0j/DzfDX8ZLJ8Lm6lWNVCDG7/yCtl39PupKIPCHPTo7arHGiykIo3LMbfjGCx2WHi2xjtAE1rmbRU+hwgUZscag2SkHo9m2pzExO0JnaEr0I/wjcduvoIeADuxneZm7edcYcq1wgH3GjfTLQbld0JeAtwBILas= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786675082; c=relaxed/simple; bh=kI0iu1iUjPc4aD0Lcu79SEz4UUJgr3m4G2Ca9n8R5YU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dK0YH20yCrnuWVIdFnwJ6PC7EUjVs+/CKHWlF5fxnQnACqDsTraEWLMGGwcWsq5fxUi3DCsXbwWjWTRkiTmJHqJl+ljr9i5ctB2sblR9WxoGJC+BjGF3ZeyjMtoUol+X/4uBr/opsYUZOp1vqjOEDs5snn6Cl6HTP+BK0Bnm/no= 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=ox2Zf4ld; arc=none smtp.client-ip=91.218.175.243 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="ox2Zf4ld" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=kI0iu1iUjPc4aD0Lcu79SEz4UUJgr3m4G2Ca9n8R5YU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786675078; v=1; x=1787279878; b=ox2Zf4ldjELrXnxfyFMDsK2AxhlfMPKYwI78NM7GO+NcP11fVN+eWr3FMVucqONVYCoUuSxn AXFKivAj+7w2paUQlVAAJimnHCFA5sMOnvlfayVck0dVGd161ay4Adi6h0VWgdP74vIy1lrCWuI 0eV964gxwyI5Sd2Nz6FOhRjQ= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [10.63.123.245] (14.29.108.90) by smtp.migadu.com with ESMTPS id f6b06a7b15b52476; Fri, 14 Aug 2026 02:37:58 +0000 X-Migadu-Flow: FLOW_OUT Message-ID: <76dd9011-84e3-45ac-a9a9-a772e5a15b1c@linux.dev> Date: Fri, 14 Aug 2026 10:37:51 +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: [PATCH v3 0/4] mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim To: Barry Song Cc: Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Zhongkun He , Muchun Song , Davidlohr Bueso , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen References: <20260723045718.2052070-1-ridong.chen@linux.dev> <20260723171842.137e45eb36b21b3b45245da0@linux-foundation.org> <8336e48a-ab3a-4db9-a7f9-5bb6af2b22c3@linux.dev> <24b9f213-96e8-4eda-a20f-8746d7c399b7@linux.dev> From: Ridong Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/2026 10:23 AM, Barry Song wrote: > On Fri, Aug 14, 2026 at 10:03 AM Ridong Chen wrote: >> >> >> >> On 8/14/2026 6:37 AM, Barry Song wrote: >>> On Tue, Jul 28, 2026 at 4:34 PM Ridong Chen wrote: >>>> >>>> >>>> >>>> On 7/24/2026 7:12 PM, Barry Song wrote: >>>>> On Fri, Jul 24, 2026 at 10:43 AM Ridong Chen wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 7/24/2026 8:18 AM, Andrew Morton wrote: > [...] >>>> >>>> So can we add just like? >>>> >>>> if ((sc->proactive && node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > >>>> pgdat->min_slab_pages) || >>>> node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages || >>>> node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > pgdat->min_slab_pages) { >>> >>> I feel both pgdat->min_unmapped_pages and >>> pgdat->min_slab_pages are quite broken in mainline. >>> >>> For example, even when the page cache is below >>> min_unmapped_pages, it may still be reclaimed. Similarly, slab may >>> still be reclaimed even when it is below min_slab_pages. >>> >>> Also, when both the page cache and slab are below their respective >>> thresholds, node_reclaim() may reclaim nothing even if we have >>> plenty of anon folios available. >>> >>> if (node_pagecache_reclaimable(pgdat) <= pgdat->min_unmapped_pages && >>> node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) <= >>> pgdat->min_slab_pages) >>> return 0; >>> >>> For example, if slab > min_slab_pages but the page cache is below >>> min_unmapped_pages, we still reclaim file pages, even though the >>> comment says we should not. >>> >>> So we are not going to introduce another broken mechanism. >>> Maybe we should start by fixing the existing broken protection >>> against reclaiming slab and page cache? >>> >> For example, Maybe we can skip shrink_slab when node_page_state_pages(pgdat, >> NR_SLAB_RECLAIMABLE_B) <= pgdat->min_slab_pages? >> >> And similarly, in get_scan_count, we could avoid reclaiming file page cache if >> node_pagecache_reclaimable(pgdat) <= pgdat->min_unmapped_pages. > > Yes, probably something along the lines of what you're saying. Also, > get_type_to_scan() in MGLRU. > > It's a bit surprising that nobody has ever reported a bug related to > this. It may have caused performance problems that we simply haven't > realized were related to this broken protection against the > min_unmapped_pages and min_slab_pages thresholds. > > I guess this fix could improve performance as well. For example, when > the inode and dentry caches are already extremely low, we shouldn't > keep struggling to reclaim them and waste time there. People have > already complained that shrink_slab() is slow and suggested having > an asynchronous shrinker for it. > Maybe it's related to something going wrong here. > Yeah, good point. I'll give it a try and run some tests to see if it actually helps. -- Best regards Ridong