From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) (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 DDB44184 for ; Thu, 13 Aug 2026 01:31:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.110 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786584723; cv=none; b=f9tztzqAUffwRICxLYLD0U4kUwgOPsoQcXGdPyWWYSOJfh0l19i9Dr0zzvbAHBZwrfFP3hDb1g663lyk1ZxvfR7FQXq/GH9/BeyuY3XX1XyDTrHKdoZLHvQKJQRJDdrW4atEbcZJLvnrTy4PVTSZbjoaMX7Xq6QMkdZGJkuW9No= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786584723; c=relaxed/simple; bh=QI2YHiqxaG/ng14GCZ7QotFAGjglcPSE0WAnMhb2sH4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ewLlSfe3rGOTiybppFRrzkkzonq8HYVUV75sI1f1VoeTGNgiOSuBlH7xPhSIwYmUFdTXBq38eOxP4Hoc+deMVbKmjWmLnUKDxf0PxlvgYrdQgi97PQeH24E5Fjvk0CCpnaZEUTfWpr4EriCsc63lOahOaBlhBxoZ4rim3LoMI64= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=FIH9oniy; arc=none smtp.client-ip=115.124.30.110 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="FIH9oniy" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1786584715; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=5N2fHbGlStAGOg6Xg0vdwBujOs3j6ONtsRuS3B8+Bc4=; b=FIH9oniyWOA78ExuUdf2eqmjooAkk9/MVQMZTGWdIybo8M21gVgNcyfCqw7cyFFnLSyzhXhAGajjA+bFFqdmtIvuCmeVABWyzwy50cirUKvTeGcHcZhNR06QIz17/rKbTQtQDDd8UypQTryH0IIjPy/F5TPPyRU8RdNamrUr9yk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R921e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---0X8sfjgK_1786584714; Received: from 30.74.144.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X8sfjgK_1786584714 cluster:ay36) by smtp.aliyun-inc.com; Thu, 13 Aug 2026 09:31:55 +0800 Message-ID: Date: Thu, 13 Aug 2026 09:31:53 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/mglru: Fix young counter undercount for large folios To: Barry Song Cc: Hui Zhu , Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hui Zhu References: <20260812065933.103627-1-hui.zhu@linux.dev> <37015686-6776-4e67-95ef-a26ac61a3b44@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/13/26 9:20 AM, Barry Song wrote: > On Thu, Aug 13, 2026 at 9:09 AM Baolin Wang > wrote: >> >> >> >> On 8/13/26 8:53 AM, Barry Song wrote: >>> On Wed, Aug 12, 2026 at 6:17 PM Baolin Wang >>> wrote: >>>> >>>> >>>> >>>> On 8/12/26 2:59 PM, Hui Zhu wrote: >>>>> From: Hui Zhu >>>>> >>>>> In lru_gen_look_around(), the young counter tracks the number of young >>>>> PTEs. The original folio's contribution is represented by the initial >>>>> value of young: test_and_clear_young_ptes_notify() is called on it at >>>>> function entry, and the function returns early if it is not young. In >>>>> the subsequent loop, the original folio is skipped (its accessed bits >>>>> were already cleared), so it is not double-counted. >>>>> >>>>> However, young is initialized to 1 regardless of the folio size. When >>>>> the original folio is a large folio with nr PTEs, its young count is >>>>> underestimated by nr - 1. This inconsistency can cause >>>>> suitable_to_scan() to return false, preventing the PMD from being added >>>>> to the bloom filter and reducing aging accuracy for mTHP workloads. >>>>> >>>>> Initialize young to nr so the original folio is accounted the same way >>>>> as other young folios in the loop (young += nr). >>>>> >>>>> Signed-off-by: Hui Zhu >>>>> --- >>>> >>>> Good catch. Please also add the Fixes tag: >>>> >>>> Fixes: 56e5b60b2114 ("mm: support batched checking of the young flag for >>>> MGLRU") >>>> >>>> With that, >>>> Reviewed-by: Baolin Wang >>> >>> Hi Baolin, Hui, >>> >>> I am not convinced this is the correct patch. test_and_clear_young_ptes_notify() >>> only indicates that there is at least one young PTE among the nr PTEs; >>> it does not mean that all of the PTEs are young. >>> >>> Am I missing something? >> >> You are right. But I explained why this is done in my original commit >> 56e5b60b2114: >> >> " >> Note that we also update the 'young' counter and >> 'mm_stats[MM_LEAF_YOUNG]' counter with the batched count in the >> lru_gen_look_around() and walk_pte_range(). However, the batched >> operations may inflate these two counters, because in a large folio not >> all PTEs may have been accessed. (Additionally, tracking how many PTEs >> have been accessed within a large folio is not very meaningful, since >> the mm core actually tracks access/dirty on a per-folio basis, not per >> page). The impact analysis is as follows: >> >> 1. The 'mm_stats[MM_LEAF_YOUNG]' counter has no functional impact and is >> mainly for debugging. >> >> 2. The 'young' counter is used to decide whether to place the current >> PMD entry into the bloom filters by suitable_to_scan() (so that next >> time we can check whether it has been accessed again), which may set the >> hash bit in the bloom filters for a PMD entry that hasn't seen much >> access. However, bloom filters inherently allow some error, so this >> effect appears negligible. >> " >> >> Based on this, I think changing it to 'nr' is reasonable. For an >> accessed large folio, it's better to have the bloom filter rescan the >> PMD and keep it in memory instead of reclaiming it incorrectly. >> > > I am not sure if this is the best policy, but we don't seem to have > a practical way to get the exact number of accessed PTEs, so this may > be acceptable. As I mentioned earlier, it seems unnecessary to implement this, since core-mm tracks access flag at per-folio granularity. Moreover, bloom filter itself allows for some error. However, could we at least update the changelog to > clarify that this is intentional? > > " However, young is initialized to 1 regardless of the folio size. When > the original folio is a large folio with nr PTEs, its young count is > underestimated by nr - 1. This inconsistency can cause > suitable_to_scan() to return false, preventing the PMD from being added" Agree. Looks better. > Its young count is not underestimated; we are intentionally > overestimating it. Also, nr does not necessarily equal > folio_nr_pages(), does it? Right.