From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 349C73932E4 for ; Tue, 17 Mar 2026 07:52:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773733930; cv=none; b=e6V9neW2+K4zYN5F7tqfMk2ytZoyseizX121PhpMX2+mZDLBP05pat/RkwSGubSxSi3oIutwPTb6ynuHr4DJz/xLgzSEmo6ZEJl8OR3i6WI5p2yKKyyAy/Ixl8p5O1AR2JHYPSHN1sVvluTzoK1XqAD7Sqm413ztSkfm9bk+ITg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773733930; c=relaxed/simple; bh=WA9E5I1h+5/aoHrpnYY5PK2hGs/x91IwSBme+keDdg8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u3Znueam+MuSTZdrIQUD2eDK+XfblFuQnl4AtYD+qmMJhncQJeQa/91EZlIJ1zcvF/XDQKKZUnsEUWTOjctr19+9YuTdGMiT6GZK2t2UCj7z4fOhnYMQ7mYtc2MgKbD6p8wdg/poA83SOzTie3L4XfZa3t7M7rgBwx5gNfm3y8Q= 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=RNrOzn5U; arc=none smtp.client-ip=209.85.128.43 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="RNrOzn5U" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-485345e1013so3210165e9.1 for ; Tue, 17 Mar 2026 00:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773733926; x=1774338726; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=n/b20VSj/vonhlO+5Zs+LrVl9EfSXfCxpUpB194z2Ns=; b=RNrOzn5UWfhcsbJHH45jfIDtLO/O7zUecE5ka8nxCqmpdc3izPRyeU5HUUvoLoYR49 gB+1Q6LvrAW3hiNn9oJ/BA/RGCrC69NJ67w5m+e2YSQlGz7aVBk/L/h0dHsmMyOJvDGn 96ZvNKz9x66S7SjDAcBIu5jNFB1e7GFksK69ZDRdi9+OImLTWDmI/VqoZ9N4gtMNcLJz AhCSl3gyoOm1CvNeVQgZwCoHS/MkaJngd0z9QuO2eqW1Ukg9U0gIBXpgVa+XvCe5uH4S LXxwV5brZYh0AV6/xrPJ/SN3iJL02S5iOGDmHMsRT+EuiBfPmc2FEtOQuOEIQGzi8qU/ FIEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773733926; x=1774338726; h=in-reply-to:content-transfer-encoding:content-disposition :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; bh=n/b20VSj/vonhlO+5Zs+LrVl9EfSXfCxpUpB194z2Ns=; b=f/nIRdO3meYgY1ml8E0HbWA82Yyx2+ffaIIzSbZzAZPVy6oHgt/MsUtU3UvPS+hmMw YqjQYebQ3qZhRuAzC93ZHvQnTUzaBPmFcoLd/X5VekjAv90XuEaHpsFmMQFbkWXwpoVm FRUhdoYbYf50l8NReRzCQ7ezSIYAbuBrevL+iZ9puH07g769nlaZR5R36MtWCZfmQHUR TDN7Ym2giseNiGgdz+zg6aiOOxQSmPMivFpZfsAZ7WzKQQx8AtjQh4cotNbW0+iRpBTe VxjpW3wWv+ra7RgNDx9uRQg6QdiZ6BL1Znb9vu4a9Zkl44VniXWxfqQUgLdchTUbAJLw l8gA== X-Forwarded-Encrypted: i=1; AJvYcCX9DbSMVb4Dr2tfL61X3/DOyW5FZRUvK6k4TEiYx4Khf6uKSmjvwrhF7xngo25zF6snM+ixVkMvc3xmxb8=@vger.kernel.org X-Gm-Message-State: AOJu0YzJGqxCSifRUGQ7XwT2EE6I0BIMA90JhpdvQz1R8L2OuDFkrMEP wQLnHoFK7OGejPoJHz8LQGU5lBZxJEaPknOX6/EfBcp10t7Oahy3TvLSQdl0raavubE= X-Gm-Gg: ATEYQzzpVLt9vcmXO+Z3W+Y/K1k89LQp1nONBKvRyqIO+QLS79889s+++iJt4drjikS IMHOvKoZsO58PWNBs9Q7+TEtJq2zZ3n0r8Cp6URjsybvc/6KZI/0zYEgYuWYpukp8CLXQZDj7vY sOZ36X9yZAAULKMMKs/7deJFQHycqTCXth/BPaghxvGNzh7kozgLAJmJJ9OzTuUpLHsrERVQ5yd sF3WbRvlPWb7QDuxgCkS8gKl2jkdbWbGbVa1jXExtn/f6Z/7iIfOBmHdMaJffWVUIagS9+cCRDe 8RRmELxyNGJHwcb7AKoucaX9vc8lDVbC/o9q0WIMZsfKWOm6t65WDOvWwR5FmqpUrSgyKaGCR24 +DbGtTt/8vRHCJQ2qsA/zMYaAdmeIyfljytPBaZmQq4ZJEiw+XZv7DELFM3Zs16eUcQnxf20Pm+ czFO1Dk8GrZzqZkqFnSnaI6zCdOPKGfCKucRui X-Received: by 2002:a05:600c:3b08:b0:483:6d9e:e4f5 with SMTP id 5b1f17b1804b1-4856eab4fccmr35026255e9.5.1773733926431; Tue, 17 Mar 2026 00:52:06 -0700 (PDT) Received: from localhost (109-81-21-195.rct.o2.cz. [109.81.21.195]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48556415294sm117998945e9.6.2026.03.17.00.52.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 00:52:05 -0700 (PDT) Date: Tue, 17 Mar 2026 08:52:03 +0100 From: Michal Hocko To: "T.J. Mercier" Cc: "zhaoyang.huang" , Andrew Morton , Yu Zhao , Rik van Riel , Shakeel Butt , Roman Gushchin , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [PATCH] mm: remove '!root_reclaim' checking in should_abort_scan() Message-ID: References: <20260212032111.408865-1-zhaoyang.huang@unisoc.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon 16-03-26 14:09:52, T.J. Mercier wrote: > On Mon, Mar 16, 2026 at 1:02 PM Michal Hocko wrote: > > > > On Thu 12-02-26 11:21:11, zhaoyang.huang wrote: > > > From: Zhaoyang Huang > > > > > > Nowadays, ANDROID system replaces madivse with memory.reclaim to implement > > > user space memory management which desires to reclaim a certain amount of > > > memcg's memory. However, oversized reclaiming and high latency are observed > > > as there is no limitation over nr_reclaimed inside try_to_shrink_lruvec > > > when MGLRU enabled. Besides, this could also affect all none root_reclaim > > > such as reclaim_high etc. > > > Since the commit 'b82b530740b9' ("mm: vmscan: restore incremental cgroup > > > iteration") introduces sc->memcg_full_walk to limit the walk range of > > > mem_cgroup_iter and keep the fairness among the descendants of one memcg. > > > This commit would like to make single memcg's scanning more precised by > > > removing the criteria of 'if (!root_reclaim)' inside > > > should_abort_scan(). > > > > This changelog, similar to its previous version is lacking details on > > what exactly is going on. How much over-reclaim are we talking about > > here? Is this MGLRU specific? > > Hi Michal, > > This came from https://lore.kernel.org/all/20260210054312.303129-1-zhaoyang.huang@unisoc.com/ > > Zhaoyang would have to provide numbers, but yes this is MGLRU specific. > > > Why doesn't our standard over-reclaim > > protection work? > > "there is no limitation over nr_reclaimed inside try_to_shrink_lruvec" > This means that for proactive reclaim the check for sc->nr_reclaimed > >= sc->nr_to_reclaim is skipped, because the !root_reclaim(sc) > condition is hit first. So we never abort based on the value of > sc->nr_reclaimed, which can lead to overreclaim. > > For try_to_free_mem_cgroup_pages -> shrink_node_memcgs -> > shrink_lruvec -> lru_gen_shrink_lruvec -> try_to_shrink_lruvec, the > !root_reclaim(sc) check was there for reclaim fairness, which was > necessary before commit 'b82b530740b9' ("mm: vmscan: restore > incremental cgroup iteration") because the fairness depended on > attempted proportional reclaim from every memcg under the target > memcg. However after commit 'b82b530740b9' there is no longer a need > to visit every memcg to ensure fairness, horray. The problem is for > large lruvecs, the lack of a check against sc->nr_to_reclaim inside > try_to_shrink_lruvec (caused by the continued presence of the > !root_reclaim(sc) check) can cause overreclaim. The non-MGLRU > implementation in shrink_lruvec already checks nr_reclaimed against > nr_to_reclaim. OK, this describes the underlying problem much better. It should go into the changelog. Including an explanation why MGLRU cannot follow the traditional reclaim bail out logic. Thanks! -- Michal Hocko SUSE Labs