From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-2.mta0.migadu.com [91.218.175.2]) (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 17C402882CD for ; Fri, 14 Aug 2026 02:03:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.2 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786673019; cv=none; b=NihIGBb8UEcg/oSjUzQxM8xq0d+POuKaqQILNVkGB3jGixAbhhC5uh5f6KO8bhYyXZMtrcKcHsCs8tfWwg0i3G5oL9UTOxOkoZu621s4cQCz+pC2TF0ErpkFLPJK/Jr04p8uqeYigtOAuTfWV3KtFJL/zye015KoDlx443whNks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786673019; c=relaxed/simple; bh=FDTPR1K3i1romvlfONK2csdHyjQzry+zjKN1gNuyHmY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LZ0exuilVxTPjFLrCtR18ULb8wdvoOINgIcwFbkVxxAuvFo4bq7+n2h/iCdTCYXQDPLWNQTcjQelLyvHVFNgrxaR0q5ELGOfZevFuHEv4Vokg/A2m3Ettu65j+U9x/PUgz8wAFtJPVBQsm3fINpYLSldGAd2UX2nKuTzVsShT/Y= 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=vp8cxxFF; arc=none smtp.client-ip=91.218.175.2 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="vp8cxxFF" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=FDTPR1K3i1romvlfONK2csdHyjQzry+zjKN1gNuyHmY=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786673016; v=1; x=1787277816; b=vp8cxxFF+RhutuJN2RgsXA49IDkpuvSJpR2oMdJuyjM/paKpx+TBhRxgutMc7LRcK+vtEXOB rLJNEDmuzD5mz87igQa8uhUsVjFFjIneLzeWuQ+oKjeJhyzRImsWTvrtefUuF+KVD0yLObo+DGn 3SGrcFpAyVNmnHwoaHUezSjM= 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 394907fbe8eec464; Fri, 14 Aug 2026 02:03:25 +0000 X-Migadu-Flow: FLOW_OUT Message-ID: Date: Fri, 14 Aug 2026 10:03:18 +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 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: >>>>> On Thu, 23 Jul 2026 12:57:14 +0800 Ridong wrote: >>>>> >>>>>> Fixes and one cleanup. >>>>>> >>>>>> Patch 1 fixes "swappiness=max": the anon-only test in get_scan_count() >>>>>> sat after the "cannot reclaim anon" check, so when no anon was >>>>>> reclaimable the request fell back to SCAN_FILE and evicted page cache >>>>>> instead. >>>>>> >>>>>> Patch 2 fixes reclaim_store() collapsing every error into -EAGAIN, so >>>>>> callers can no longer tell an invalid argument from a busy interface; >>>>>> propagate the real error code, matching the memcg path. >>>>>> >>>>>> Patch 3 drops the now-unused gfp_mask parameter from __node_reclaim(). >>>>>> >>>>>> Patch 4 fixes the same "swappiness=max" issue for MGLRU. >>>>> >>>>> Thanks. AI review might have found several pre-existing issues which >>>>> might interest the maintainers. Also a suggestion against your [4/4]: >>>>> >>>>> https://sashiko.dev/#/patchset/20260723045718.2052070-1-ridong.chen@linux.dev >>>> >>>> Hi all, sashiko review: >>>> >>>> This is a pre-existing issue, but I noticed that per-node proactive reclaim >>>> fails to reclaim memory if the node's unmapped file or slab pages are below >>>> minimum thresholds, completely ignoring anonymous memory. >>>> In mm/vmscan.c:__node_reclaim(): >>>> if (node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages || >>>> node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > >>>> pgdat->min_slab_pages) { >>>> Does this condition incorrectly block proactive reclaim of anonymous memory >>>> by applying legacy zone-reclaim thresholds? >>>> It seems to bypass shrink_node() entirely if file/slab pages are low, even >>>> when sc->proactive is set, which could falsely return -EAGAIN to userspace >>>> for anon-heavy workloads. >>>> >>>> Should we add: >>>> >>>> if (sc->proactive || >>>> node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages || >>>> node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > pgdat->min_slab_pages) { >>> >> >> Hi Barry, sorry for the late reply. >> >>> Nop. >>> I assume reclaiming file cache and slab becomes problematic when their >>> amounts are already very limited, so we should still honor these two >>> checks. >>> >>> Maybe we could relax them only when swappiness == 201 >>> (SWAPPINESS_ANON_ONLY)? >>> >>> BTW, for global proactive reclaim, when setting swappiness to 201, does >>> it prevent slab shrinking? If not, it seems problematic when >>> node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) < >>> pgdat->min_slab_pages. >>> >> >> in __node_reclaim, we will shrink the node when >> node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages, even if >> node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) <= pgdat->min_slab_pages. >> This means slab shrinking can still occur even when below the limit (since >> shrink_slab is called unconditionally after shrink_lruvec). This is not an issue >> only for global proactive reclaim. >> >> >>> Your recent patchset prevents all file reclamation when swappiness is >>> set to 201, so we only need to check whether there could be a slab issue >>> before allowing shrink_node() to continue in this case. >>> >> >> 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. -- Best regards Ridong