From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) (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 13EB32931C8 for ; Fri, 24 Jul 2026 02:43:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784861017; cv=none; b=ObOOqe+9uZrvWV93tJon17JKYkxq7zx2pCYDiLo9HbB0WfcaJpGIWGeXpss/Z3O0bsEH91VN3PtKMUMSVEHc25AVA9tQI4D1dewX+0d7/Plz24ezv4ao3hIHR0gUZ2r7gMGBqVKWBmW3ab/C99Qqo90KW4YqCw4sMDjI03RoWSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784861017; c=relaxed/simple; bh=qNEGqPUf991qNKucxvE8Kq04e8j3uybUJfJnkPgNuBQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=G3hTzlfX8QXMaLR0mro1GWb0UhAWBvFl4GldksgHAgjWLEI83tdXwqusU8Qd7wtfgp7xpn1cLkeWxeFB0WmkBynZUCjewJ0puaMRjPI6ibJ62wZ/Xh4tPfF3QT0pwASw9rq6cPiC7JPczhtx985SFLIZQxyKLrGGmQPgcd5Y+Fo= 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=DnsTpQu6; arc=none smtp.client-ip=95.215.58.173 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="DnsTpQu6" Message-ID: <8336e48a-ab3a-4db9-a7f9-5bb6af2b22c3@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784861012; 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=bDCqTywiR4s5nLQyaf6i50wmBQjCRcVwZ9olAr2XKwM=; b=DnsTpQu6+6hScxk3UNzHkxZ+9oUCyQoZu3i6pZIRcPs6V5oPVGV+fGVxbo2cHPs8fq6isl UlEBUVPrZBt/ciDvZZREkRR41w5enOI7A3d39Qdm/elQTUIykkXPqO/3VMY64Q2/koJTYK X9va7hKIQ6OCHzf8nd67U7o9/N2O+yk= Date: Fri, 24 Jul 2026 10:43:22 +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: Andrew Morton Cc: Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry 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> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ridong Chen In-Reply-To: <20260723171842.137e45eb36b21b3b45245da0@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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) { -- Best regards Ridong