lkml.org 
[lkml]   [2024]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH v3 1/8] mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true
Date
Yuanchu Xie <yuanchu@google.com> writes:

> When non-leaf pmd accessed bits are available, MGLRU page table walks
> can clear the accessed bit and promptly ignore the accessed bit on the
> pte because it's on a different node, so the walk does not update the
> generation of said page. When the next scan comes around on the right
> node, the non-leaf pmd accessed bit might remain cleared and the pte
> accessed bits won't be checked. While this is sufficient for
> reclaim-driven aging, where the goal is to select a reasonably cold
> page, the access can be missed when aging proactively for measuring the
> working set size of a node/memcg.
>
> Since force_scan disables various other optimizations, we check
> force_scan to ignore the non-leaf pmd accessed bit.
>
> Signed-off-by: Yuanchu Xie <yuanchu@google.com>
> ---
> mm/vmscan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 4f9c854ce6cc..1a7c7d537db6 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3522,7 +3522,7 @@ static void walk_pmd_range(pud_t *pud, unsigned long start, unsigned long end,
>
> walk->mm_stats[MM_NONLEAF_TOTAL]++;
>
> - if (should_clear_pmd_young()) {
> + if (!walk->force_scan && should_clear_pmd_young()) {
> if (!pmd_young(val))
> continue;

Sorry, I don't understand why we need this. If !pmd_young(val), we
don't need to update the generation. If pmd_young(val), the bloom
filter will be ignored if force_scan == true. Or do I miss something?

--
Best Regards,
Huang, Ying

\
 
 \ /
  Last update: 2024-05-27 16:30    [W:0.120 / U:4.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site