From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 F1639308F32 for ; Tue, 17 Mar 2026 13:50:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773755459; cv=none; b=o7Jt3p6XtYcRBxmYEL7zSy8LmUYSuuEc1N90/GPS59dkjoNYGdYOCOEuXDn1ZGBH9f671fwgVOtZXEQTVUH6wOwjZ+6nud4nnOsOWKtvxVviB059HV71pMTQMyNT1ksujRRlu36pDzHIcGBrvV1L4bz+ZNOQEvalhrJU91Ul5kQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773755459; c=relaxed/simple; bh=RubO6IbeRmWzPDwPBa8viZy27gE9csu6j8iYq/7blFI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ad5HWbB9sli6iAXeN8KHh0oH4uI39R/Js5kTyWX3q4eFjvUwrBvNdhvxBSrUqDuBMlqXgD5wt8T+cxRIL1onWLIcMjiFO2Y06AiF6LCUjbsPmDTvMOjfHJdJElqWWt4zfHK8AigoSkpNq7PVJ4ZRZeuiOGcPkJFAmhFn6YG86HY= 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=KBHmjxUl; arc=none smtp.client-ip=209.85.128.42 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="KBHmjxUl" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-483487335c2so55038465e9.2 for ; Tue, 17 Mar 2026 06:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773755456; x=1774360256; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KrJcq8GiXxMyinwAoqRMnMTIBXNzfOAtBfNZI3AE1A4=; b=KBHmjxUlnFZFWlfX9a0kkriPq6CVoyJCHncEJCEfVKRGPI0cYKtQP7pTkZ6dzvdct+ oEo9SaiIpUwGQ/ZZyVWhY4ZghV5md+Ctw3SuXltAujq0CcMkyxe7lk7kWICkTSDa+698 5HUD8deQ4Tgbu7MTKgbqga6LccgK6Zcyh7zv9hT+SClKIRXek5HfH6WIfA1I8rVqkMhn sfNzYRGY20C5iuDAAm7UfG87ffkyjkONfjMcarkqLcY/5v/mUnvqvL5x+GCJd99hIhI/ x09bpBcayZrF5CHQ9MJ63QGEtsQ9SCLbYYfcliH/WRu8i/Rov3vb2fztUIP6bfb0coFg 7d3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773755456; x=1774360256; h=in-reply-to: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=KrJcq8GiXxMyinwAoqRMnMTIBXNzfOAtBfNZI3AE1A4=; b=FGpjsiKDQqhAPHW/NrEbJP6X8JgCIZAHsy5CfdU1kSN5DBFU39nbfgPmQhLgUFvplj A4hFEcprs5XDcKjAwtCWGq+9oqXnaEMV4/NoJCzQMoVN4wW7vRGEO4E4Ls5s3FmbLTn0 BxU5DFklqMXBoMSP2/i28BeZtZL3zDH/mdMK1i9v5co6ZTeaJie3cc0XnO3ehbe1FLwI 6SiIjiczRvJoW3zreMa9cwcJYnTl2C/hETT1mKszvG5LWoWjhvT/OcdBHn9h4RUqGGo4 IW0S56ETBaVeQDu4vQBDF+BXwITtpZ8Ak6mrm1xgEl1wGBpbrBrJlIiyGtLoOHuzhxaS FRGQ== X-Forwarded-Encrypted: i=1; AJvYcCXsAm96+0o+sNRw1Gpl5Ber4XB3hPCdvcAq2uHCgYDU+hKIRGCNbH2Vm6kgCEtlfo2SplFWWS5tNQoyo5s=@vger.kernel.org X-Gm-Message-State: AOJu0YzqLE+tt5fI4biEZC3Wp1yCSsxgysrMaW/z02RDopChDGmlV3k5 +a3Qa8bv4JV7QchbXfm0SWcLkmYHKiwdSwqa+JujsU/GcW4oNSteCyH37622WxjPlwg= X-Gm-Gg: ATEYQzz8Hxyq/tX9fJLeMgK8Zh4ngt12E9u/NTRECYl3dI2T/ryZcYHnw5c/50umwBQ 4RtCEj6P5uNowNnEaxn6oy2TKH2ZXlpRF9VzkQ1xVVNMwG1rB77rhLJvilnoh3j8gofStx8oSRa KheDtghqj0T0P4SgyPhAPi42XOGxiCP+8o4dAXgO6zpO86+CAC5q5NeNgAtaIyVSZ5tRpYvhXJ5 qMey0ptoynYIAQVQJx0bjpVlp+8cUUNeopVITD/hE6p7Z3idVOsg8N6OeljNHrfFp/mKayyFcel JSMeW8mHOyFudz6bWCaDpEp/pFxlAywv+ZpixLr+FAqu/SoBsYH7sAFNZToBo3eOA4iDbIWb4vO EZE5iqJAt5VC9f6VM+mB3jD+U7yTL79TEwPNabunwCwVxtqh/K/S4C3pgghhIPQ+YY1/g4mPByn 5wZSPLj+pdXL2TJE5DxseW9HfHXgeJk+cAHloa X-Received: by 2002:a05:600d:8488:10b0:480:3ad0:93bf with SMTP id 5b1f17b1804b1-485567060a1mr208600275e9.24.1773755456223; Tue, 17 Mar 2026 06:50:56 -0700 (PDT) Received: from localhost (109-81-21-195.rct.o2.cz. [109.81.21.195]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4856ea8fb0dsm123490165e9.3.2026.03.17.06.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Mar 2026 06:50:55 -0700 (PDT) Date: Tue, 17 Mar 2026 14:50:54 +0100 From: Michal Hocko To: "zhaoyang.huang" Cc: Andrew Morton , "T . J . Mercier" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [PATCHv2] mm: remove '!root_reclaim' checking in should_abort_scan() Message-ID: References: <20260317123037.1651424-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=us-ascii Content-Disposition: inline In-Reply-To: <20260317123037.1651424-1-zhaoyang.huang@unisoc.com> On Tue 17-03-26 20:30:37, 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 > [1] 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. > 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. I usually do not insist on a specific format of the changelog but the above is just hard to follow. I would rephrased and reformated as follows. " Android systems usually us memory.reclaim interface to implement user space memory management which expects that the requested reclaim target and actually reclaimed amount memory are not diverging by too much. With the current MGRLU implementation there is, however, no bail out when the reclaim target is reached and this could lead to an excessive reclaim that scales with the reclaim hierarchy size. To address this issue drop the root_reclaim exception from should_abort_scan. This was necessary to achieve reclaim fairness but b82b530740b9 ("mm: vmscan: restore incremental cgroup iteration") has addressed that issue and visiting every memcg to ensure fairness is no longer required. " > > [1] > test log which shows a nr_to_reclaim=32 pages proactive reclaim ended with > nr_reclaimed=394. > > [ 485.100981] memcg iter ffffff8086535a00 nr_to_reclaim 32 nr_reclaimed 0 > [ 485.106927] memcg iter ffffff8086535a00 nr_to_reclaim 32 nr_reclaimed 127 > [ 485.109652] memcg iter ffffff80744e1400 nr_to_reclaim 32 nr_reclaimed 127 > [ 485.112255] memcg iter ffffff80744e4600 nr_to_reclaim 32 nr_reclaimed 127 > [ 485.115766] memcg iter ffffff8150306e00 nr_to_reclaim 32 nr_reclaimed 191 > [ 485.125635] memcg iter ffffff8157608a00 nr_to_reclaim 32 nr_reclaimed 191 > [ 485.131366] memcg iter ffffff8157754600 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.136688] memcg iter ffffff8157752800 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.140495] memcg iter ffffff8157755000 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.147322] memcg iter ffffff8159461400 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.150605] memcg iter ffffff8159466400 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.158260] memcg iter ffffff8159460a00 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.160819] memcg iter ffffff8159460000 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.163200] memcg iter ffffff8159463c00 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.171778] memcg iter ffffff808912ee00 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.174156] memcg iter ffffff808912a800 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.179110] memcg iter ffffff814bd3a800 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.181537] memcg iter ffffff814bd39e00 nr_to_reclaim 32 nr_reclaimed 216 > [ 485.184877] memcg iter ffffff814bd3da00 nr_to_reclaim 32 nr_reclaimed 219 > [ 485.187245] memcg iter ffffff814bd38a00 nr_to_reclaim 32 nr_reclaimed 219 > [ 485.189654] memcg iter ffffff814bd38000 nr_to_reclaim 32 nr_reclaimed 219 > [ 485.192029] memcg iter ffffff814bd3bc00 nr_to_reclaim 32 nr_reclaimed 219 > [ 485.194509] memcg iter ffffff814bd39400 nr_to_reclaim 32 nr_reclaimed 283 > [ 485.197107] memcg iter ffffff814bd3c600 nr_to_reclaim 32 nr_reclaimed 330 > [ 485.201361] memcg iter ffffff814bd3ee00 nr_to_reclaim 32 nr_reclaimed 394 This is a lot of bloat without a very limited information. It would have been much more useful to describe your specific situation. How does your reclaimed memory hierarchy looks like, what is the requested memory reclaim target and what how much memory has been actually reclaimed. Now compare that before and after the patch. > Suggested-by: T.J.Mercier > Reviewed-by: T.J.Mercier > Reviewed-by: Michal Hocko I haven't given my Reviewd-by! Just participating in the discussion doens't imply any tag. > Signed-off-by: Zhaoyang Huang > --- > Patchv2: update commit message > --- > --- > mm/vmscan.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 0fc9373e8251..10f1e7d716ca 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -4839,10 +4839,6 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc) > int i; > enum zone_watermarks mark; > > - /* don't abort memcg reclaim to ensure fairness */ > - if (!root_reclaim(sc)) > - return false; > - > if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order))) > return true; > > -- > 2.25.1 -- Michal Hocko SUSE Labs