From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (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 9BDAA385502 for ; Wed, 8 Apr 2026 08:43:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775637825; cv=none; b=hFg4GRX+hUia67fLYptYDTNrWuRDeov3ig2/2hyEaIWWmBkbeNANNTVOrfwH3nA7dhEnZv8KIuXHnrECi8QaLkbbKK02aFBDRhC63+pfMmOiAPeP4OVg+WKJr1K63aRa7YWdAI7p7/0qgOozY1WUfct2VDePk4d0wnzTI/nMLJ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775637825; c=relaxed/simple; bh=LDITF/VjnD4hEFVNwinVWnjG/h2CNDYMzUEFqYKw+tU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WMUlWXr1DKaG+WM0UxT2SVuV9CBHBrbpTRm6/7c3XAGvLxJk0NqTLA1jQVkRhQdpDyugoRjjhk6pbgQsVSAigplp7ZmOAzLw8iRj7oC4C1YD8kkD49wyKpBZvamlv/C6xkZaMaC0O9//GH6e3qwC1GoEdWmIX4/pgtYIUaMhdro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AZHKVkuz; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AZHKVkuz" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-35d94f4ee36so3478395a91.3 for ; Wed, 08 Apr 2026 01:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775637824; x=1776242624; 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=lDUg5Y8vVTIzFl3YbIlPH9lZElpr4/5T9t8qsPiD1uM=; b=AZHKVkuz3I92jxOaTSEceyJj48IzhRHzwLa+QdmGbKsC+D0A3hJlj3JQvO8QBQDfpC C80ix8KBPjlQkWbQ/m6xvUJ1qr0Bq4z0gJXdSrT9SwdHNFuxhkdTN4bg078HohfUcyo9 dOO4VE633EIFVawQNAiQuWT+kQkZTMJrEqrkATUHWUe129bi7Sly1ncZDGHhGIbKW+dM he6XYZJZHnWhfDaHRG2YHNkHmd8sCqvTw6vuwqwWtVs7eUCBgBRVt9NhI+Dc9YfSldHh ZEf3nWVNfcGi13cmUnYY+qaw0hdWx8X1Fh3z/oYFiX6GTfgdDMM4oNi5I2m3zZujlG4x kHcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775637824; x=1776242624; 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=lDUg5Y8vVTIzFl3YbIlPH9lZElpr4/5T9t8qsPiD1uM=; b=DgxvQoy+xDv+ovETBDpjXBFjbkO/OU7l3bzE0uzKwoIIXpUjh22xMsbjB4LtLQP9ho fJBaQdcohbGBusNU4A/2uxkSNA9y8aeYJNB3NPlS6PZ7NkCPxo9VtUyecYSap3fj9slu x5nbavju30cKRlfs/ckFN8FZWSH1prYd69d5eKlOocIMZYRrDGIonCfMF9P/z4fg9lMg E7lUZeMkoE2Q85lFOcF9z2pQAbhrs+wSblIbQ9EaqF3lWmNJqBNH3mip8CPlBBMk0dS9 qAlaK1doLO7Pq7TTFtCeWcuLr9fVeRBbE/WEJjmiLd1klqD7LHvHg9m3EXVTtRopvdGy zyAg== X-Forwarded-Encrypted: i=1; AJvYcCXxGXTDYrfmRXG5mCnoG+POI74wVtn/cUVzlXHRU/kSNTIHJegp8sY8fDnIP4lv214EnBFqowx8eP78uHM=@vger.kernel.org X-Gm-Message-State: AOJu0YxSXrvp8szGD9PJicIO8kyN2W9mwAYMlkJw9nle0Ud/zyGiqLHY rTJo8VkTQqzs5ud5SM+KwpByFUeGSIjAUW+q5wmzVSF5HGhDQmXE1HBt X-Gm-Gg: AeBDiesJ2ZAiaI+Sfiq3qbg+Xc8MkxWwfrL1VzZhCLnw9QnPRLQ/ZVvg4KIMVpdVz9u rBwvjUTmB2b1Tlz1MZpkBbXLqCuGFcnMvEEfuDHpyOAyp9kIVWKr+WNtnRyxeKEcUYHQQ/QR7zS OmEeFxsbwwTTck8tsoPQSf778tudXyfR+MEiQ27cYnbDtJSpNBOZ4LVXY+W+6KZROy/U1k73HNv wwhwm4/CLS+UN3WX9Q56U40EZykxSAZA+8UmKzDXrsxykCV3LMc2Bd1EsiEY7GYEPBq/DGH2kjQ REKn0HjyvInKrvosXtQARX3ARW9P2cBu04kyqWDZ58kQ4AvotOY+8Z+M/kGztVfhumxo2CWfvVC QLh9N2mAMfhky6BTcFbyaaMqw31LtZLPJ8w4RY87NMn+gCh8TgNo8T2VzC/YlYIozZD6r78w8xa XG46H0wZ0I4xULL6wgFcuO97FGoq2vNUEwcKus1P4uL68f6DuvHVS6MMi2MAfLYW2Yv28v X-Received: by 2002:a17:90b:4b92:b0:35b:e4d8:e21d with SMTP id 98e67ed59e1d1-35de678f2c8mr19167142a91.2.1775637823840; Wed, 08 Apr 2026 01:43:43 -0700 (PDT) Received: from KASONG-MC4 ([43.132.141.20]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b2749ecbd1sm293654065ad.83.2026.04.08.01.43.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 01:43:42 -0700 (PDT) Date: Wed, 8 Apr 2026 16:43:35 +0800 From: Kairui Song To: Chen Ridong Cc: kasong@tencent.com, linux-mm@kvack.org, Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org, Qi Zheng , Baolin Wang Subject: Re: [PATCH v4 04/14] mm/mglru: restructure the reclaim loop Message-ID: References: <20260407-mglru-reclaim-v4-0-98cf3dc69519@tencent.com> <20260407-mglru-reclaim-v4-4-98cf3dc69519@tencent.com> <997d5991-6935-49ac-8aa7-569767c4693b@huaweicloud.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: <997d5991-6935-49ac-8aa7-569767c4693b@huaweicloud.com> On Wed, Apr 08, 2026 at 04:08:05PM +0800, Chen Ridong wrote: > On 2026/4/7 19:57, Kairui Song via B4 Relay wrote: > > +/* > > + * For future optimizations: > > + * 1. Defer try_to_inc_max_seq() to workqueues to reduce latency for memcg > > + * reclaim. > > + */ > > static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > > { > > + bool need_rotate = false; > > long nr_batch, nr_to_scan; > > - unsigned long scanned = 0; > > int swappiness = get_swappiness(lruvec, sc); > > + struct mem_cgroup *memcg = lruvec_memcg(lruvec); > > + > > + nr_to_scan = get_nr_to_scan(lruvec, sc, memcg, swappiness); > > + if (!nr_to_scan) > > + need_rotate = true; > > > > Will it be simpler if we return directly here? > > if (!nr_to_scan) > return ture; Looks good to me, I used `need_rotate = true` here since it kind of explains what is happening better. > > I wonder if moving the aging check under `while (nr_to_scan > 0)` can change > behavior when the scan budget gets shifted down to 0. > > In the old code, once `should_run_aging()` became true, reclaim could still go > through `try_to_inc_max_seq()` instead of being gated by the priority-shifted > scan budget. With this change, a small lruvec can skip the loop entirely, so a > lruvec that needs aging to make reclaim progress would neither scan nor age in > that reclaim round. > > Does this have any observable impact on reclaim progress or reclaim balance, > e.g. by deferring aging until a later retry / higher priority and pushing more > pressure onto other memcgs? We also skip aging unconditionally at DEF_PRIORITY, both before and after this patch. Scan budget can only be shifted to 0 when the memcg is smaller than 8M. Seems trivial to me, maybe I can just restore below code in V3: if (!nr_to_scan) nr_to_scan = min(evictable, SWAP_CLUSTER_MAX); https://lore.kernel.org/linux-mm/20260403-mglru-reclaim-v3-4-a285efd6ff91@tencent.com/ Was a bit worried that tiny cgroups could get over reclaimed, so maybe: if (!nr_to_scan && sc->priority < DEF_PRIORITY) nr_to_scan = min(evictable, SWAP_CLUSTER_MAX); I tested the reclaim balancing issue using selftests/cgroup/test_memcontrol, all looks good with whichever design as the cgroups there are >16M hence not effected. I think we might be over thinking about this :)