From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (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 22B452EC0A7 for ; Fri, 21 Aug 2026 08:31:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787301073; cv=none; b=moE1Rn8Xj2+zIr4g5C8YemoOL48OUS3bWDoMAJyutKb8pYPvVXFAaZBFjyX4Gi+05td34rsh+JKSFESsDrwGVqLMoj4miV1+PWecnkaki5grx/2G9c+xyEZPenbnE/hPOLokhD2fsvkEzIlVFTAf04QRsOm2361CrtI3PDSmYRg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787301073; c=relaxed/simple; bh=zkzHJv3XsMb1r+y0+JjAJ2yKV/b3RW4SdLEzhpr+8ow=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IphuJle9PUOKFlmG1sDpL11Phn0dSHU4votcObIeo7tVVg3jsBOMbsrIhLYO5iTN7qfHturIMuKyfAHmnjpmX3M7ZJY4KakzkdISYWqMJhbwJONLvl4ueMwL78UE8E28VEfCbDeE8CkAN+yjyIYVqM/ft3cSN9YbZJtw873rp2I= 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=GPECM2D4; arc=none smtp.client-ip=209.85.218.45 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="GPECM2D4" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c20e70a0962so112380766b.2 for ; Fri, 21 Aug 2026 01:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787301069; x=1787905869; 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=VAHzhpOzsSEr244aJxDSo4vPO1nJblSYlEfL1siC080=; b=GPECM2D4RHIn5AVdsS+cPBzjE1ZrONkZCE2Vd0ab6SjIELciGnGDd14QWQz0oIiVxN 2Jh4VfTzw4IOp94kG5LM44VEc+xn7aerrStRrSceybGPO/P6zv6p1RDPIfuOcI0SyIai mCLfGWHcQT7U2xcpff67sDoyJGf0MfrIPfAh4BB0xcTcBd1GvLJ/WR0rRn/feiKiJIMo umHg6kOUZF43sxpjE8y6f/yRBoGRbYwy8QN5K82Voy0HzpHiWMpxTGJwmuRxRcqK33w/ AeYfKaK1UDjQjbxNQb9ikvdGJj6zTQPzwD8LWagqHhDfN+mmrktneOXTSesakGBHHjVP 9U6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787301069; x=1787905869; 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=VAHzhpOzsSEr244aJxDSo4vPO1nJblSYlEfL1siC080=; b=Skkydf6eCYVDZxDim7fbGg+T5tHESMousluPUFhNiEcnS/G01MmnFitlCa5IVMXXRN ojI2xwQrA/YZtOZnTeb1p5AiznJld1VpuxhwQv9cxQnmnAWNSweerflaa+ze59DgtROo WWnyoffQBido7DtYQlEB2dQO8Lht7N2fiZ37EVTKkVv3ZhC83gjEWF3jOx/deFsZskNX UVXHL23PR5nfrZ4uFsSkYRj0pQPdJYMUnjiykrX3QlDy1bhjWUQSd8BEXDC5zSKwSYiX kunT9ux/xOapGkn6NSuN8CGQ6DDTLet+c/m2aYXbssaANVgEMNGqKyCIGHT8UqxdiAs6 5e6w== X-Forwarded-Encrypted: i=1; AHgh+RrpQvFmo1aKZnANxqt75Pvg5QofDVICjUM6XwqVX/v83B8B0Tmyif8zQCoJ1YRJ6J5eWHq+HSkyVP+pNsQ=@vger.kernel.org X-Gm-Message-State: AFuF++n2rH+ruqfZJxMPeVk8oY9Z4mkkvK9LX65MbleVBhsD0/S7eK+9 dojWR0kNRO7SIb7nL/+9WVDhJ4o9dWxJesbmrbDunUVhklJbxXGDsKZsSyJ7JP4GKzU= X-Gm-Gg: AR+sD133Dqm7I0Te1Ws/lUBfNEV9AFW2pFvtRsyFQV7tkOPk6d01ms2tpg36cQb8cmU Vt19mFgX/C0KneXCmiI/UVTfhVVLVz7BhY8QU907q4pT0s6ms6Dxwv9jY9YwtHUS5dtpDM8XQUe maM6LXHJ9RjLmC+aENwZAC3hEHiWVw5hF4jz7QNDExDTO2XI/XvWDZJTmXeP8s4j3h2xOnSIAFz 19cAUjw9oNP01tgq8wwXju3iBWMIsRJZqMVwxJRn2ov2RQOpzMD9Rqpo64yhvTBh8bCniUdeft5 M8QGFKJ9wbGiY6pt4TqXgPaygMlMlJUyGWOUhJNIFV1pzN92eFRhXAc3We8azrR6+yTpDxLxeGX 7njz0R6iFlE9ejPExlC4l3GabFebTENjtfWQP99Xy4UkGzLy6QJAHLmVDmOf7xAkuX1cjDGQ72c hl1+pTK6mgPoc4lKM/8W97Te+0uAKaarwlhnDOMCVxL4jHDjrd8sggWHaMWvvZ4KMhRWLW4OfhH Q== X-Received: by 2002:a17:907:e00c:20b0:c20:23f8:99a5 with SMTP id a640c23a62f3a-c246a6a402cmr349309766b.15.1787301069301; Fri, 21 Aug 2026 01:31:09 -0700 (PDT) Received: from localhost (109-81-81-112.rct.o2.cz. [109.81.81.112]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24591979e6sm424948966b.33.2026.08.21.01.31.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 01:31:08 -0700 (PDT) Date: Fri, 21 Aug 2026 10:31:06 +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: <20260821081741.1340277-1-ridong.chen@linux.dev> 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? > Tested on QEMU (x86_64, 2 NUMA nodes), A/B kernels differing only in this > series. > > Proactive reclaim (echo to node/reclaim) on an anon-heavy node, file and > slab under their limits: > > metric before after > ----------------- ------ ----------- > pages reclaimed 0 MiB 254 MiB anon > return value -EAGAIN 0 > > Node reclaim (zone_reclaim_mode) with one type under its limit -- the type > under its limit must be left alone: > > type under limit before after > ----------------- ------------- -------- > slab 645 scans 0 scans > page cache 83 MiB scanned 0 MiB > > [1] https://sashiko.dev/#/patchset/20260723045718.2052070-1-ridong.chen@linux.dev > > Ridong Chen (4): > mm/vmscan: only reclaim slab in node reclaim when over min_slab_pages > mm/vmscan: only reclaim file pages in node reclaim when over > min_unmapped_pages > mm/vmscan: drop the combined limit gate in __node_reclaim() > mm/vmscan: do not skip node reclaim when only anon is reclaimable > > mm/vmscan.c | 89 ++++++++++++++++++++++++++++++++++++++++------------- > 1 file changed, 67 insertions(+), 22 deletions(-) > > -- > 2.34.1 -- Michal Hocko SUSE Labs