From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7CDB40A943 for ; Tue, 28 Jul 2026 08:33:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785227635; cv=none; b=dqfhGvCSIoRYdnT6rxAUskq7D0qkG7BdylzdifOFJABkH+CxBu6CyGFsEhjV6Z0saSGU+LRWOpC4AUqFPz9Ot3bMwi2RQHZvSb1SIClTyq0elZyLMzSLGD/B6z9ZHXSfIZRtdbpYpY2Fq2RfYT5rasqkV4Vhdtzw+UE76YLlBF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785227635; c=relaxed/simple; bh=L0eu7a3gG9AWzeRYkx7IkjV1pkjNo+jEpAVPN2cttXU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HHi2F1ceAbkBxBFPQh7dMjI5tv7HEdKblx97F49wBiFJyq095Klkx7ipKYF9DrV4kDr7ptFVQFQ4tOsogsF/2iQaXDZvXspOsU69rrujh+P4bxn7NvDze6C6pgLxFpNyQneHSazlv08KFtGa2tMw+aJD6/RrZ5A0PxizI21Bl9I= 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=HsT3ezX3; arc=none smtp.client-ip=95.215.58.181 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="HsT3ezX3" Message-ID: <24b9f213-96e8-4eda-a20f-8746d7c399b7@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785227627; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X1OAr0wARt/pkmfsKUtroNqFk1WpnC6NGf/q2G4G+OE=; b=HsT3ezX3XlyvCAN/4AtbXu4YWl0QPD5oKLSCL22Zygw504c16hhj4wnT4pDRT0ekqOEwhw qtXjJccfgaKB+ZP7qWAm5SjWBM2ha/BpR2rzULKwxJ4wJ4EOu/PjuDI4aueK6I2QeyWSzQ ySBOtRPBuap+gsK7uc9gZFWBIu9Abpg= Date: Tue, 28 Jul 2026 16:33:31 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ridong Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 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) { -- Best regards Ridong