diff mbox series

[v2,5/5] mm: add per-order mTHP swpin_refault counter

Message ID 20240409082631.187483-6-21cnbao@gmail.com (mailing list archive)
State New
Headers show
Series large folios swap-in: handle refault cases first | expand

Commit Message

Barry Song April 9, 2024, 8:26 a.m. UTC
From: Barry Song <v-songbaohua@oppo.com>

Currently, we are handling the scenario where we've hit a
large folio in the swapcache, and the reclaiming process
for this large folio is still ongoing.

Signed-off-by: Barry Song <v-songbaohua@oppo.com>
---
 include/linux/huge_mm.h | 1 +
 mm/huge_memory.c        | 2 ++
 mm/memory.c             | 1 +
 3 files changed, 4 insertions(+)

Comments

SeongJae Park April 10, 2024, 11:15 p.m. UTC | #1
Hi Barry,

On Tue,  9 Apr 2024 20:26:31 +1200 Barry Song <21cnbao@gmail.com> wrote:

> From: Barry Song <v-songbaohua@oppo.com>
> 
> Currently, we are handling the scenario where we've hit a
> large folio in the swapcache, and the reclaiming process
> for this large folio is still ongoing.
> 
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> ---
>  include/linux/huge_mm.h | 1 +
>  mm/huge_memory.c        | 2 ++
>  mm/memory.c             | 1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index c8256af83e33..b67294d5814f 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -269,6 +269,7 @@ enum mthp_stat_item {
>  	MTHP_STAT_ANON_ALLOC_FALLBACK,
>  	MTHP_STAT_ANON_SWPOUT,
>  	MTHP_STAT_ANON_SWPOUT_FALLBACK,
> +	MTHP_STAT_ANON_SWPIN_REFAULT,
>  	__MTHP_STAT_COUNT
>  };
>  
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index d8d2ed80b0bf..fb95345b0bde 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
>  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
>  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
>  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
> +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
>  
>  static struct attribute *stats_attrs[] = {
>  	&anon_alloc_attr.attr,
>  	&anon_alloc_fallback_attr.attr,
>  	&anon_swpout_attr.attr,
>  	&anon_swpout_fallback_attr.attr,
> +	&anon_swpin_refault_attr.attr,
>  	NULL,
>  };
>  
> diff --git a/mm/memory.c b/mm/memory.c
> index 9818dc1893c8..acc023795a4d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>  		nr_pages = nr;
>  		entry = folio->swap;
>  		page = &folio->page;
> +		count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>  	}

From the latest mm-unstable tree, I get below kunit build failure and
'git bisect' points this patch.

    $ ./tools/testing/kunit/kunit.py run --build_dir ../kunit.out/
    [16:07:40] Configuring KUnit Kernel ...
    [16:07:40] Building KUnit Kernel ...
    Populating config with:
    $ make ARCH=um O=../kunit.out/ olddefconfig
    Building with:
    $ make ARCH=um O=../kunit.out/ --jobs=36
    ERROR:root:.../mm/memory.c: In function ‘do_swap_page’:
    .../mm/memory.c:4169:17: error: implicit declaration of function ‘count_mthp_stat’ [-Werror=implicit-function-declaration]
     4169 |                 count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
          |                 ^~~~~~~~~~~~~~~
    .../mm/memory.c:4169:53: error: ‘MTHP_STAT_ANON_SWPIN_REFAULT’ undeclared (first use in this function)
     4169 |                 count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
          |                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    .../mm/memory.c:4169:53: note: each undeclared identifier is reported only once for each function it appears in
    cc1: some warnings being treated as errors

My kunit build config doesn't have CONFIG_TRANSPARE_HUGEPAGE.  Maybe that's the
reason and this patch, or the patch that introduced the function and the enum
need to take care of the case?


Thanks,
SJ

[...]
Barry Song April 11, 2024, 1:46 a.m. UTC | #2
>> +		count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>>  	}
>> 
> From the latest mm-unstable tree, I get below kunit build failure and
> 'git bisect' points this patch.
> 
>     $ ./tools/testing/kunit/kunit.py run --build_dir ../kunit.out/
>     [16:07:40] Configuring KUnit Kernel ...
>     [16:07:40] Building KUnit Kernel ...
>     Populating config with:
>     $ make ARCH=um O=../kunit.out/ olddefconfig
>     Building with:
>     $ make ARCH=um O=../kunit.out/ --jobs=36
>     ERROR:root:.../mm/memory.c: In function ‘do_swap_page’:
>     .../mm/memory.c:4169:17: error: implicit declaration of function ‘count_mthp_stat’ [-Werror=implicit-function-declaration]
>      4169 |                 count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>           |                 ^~~~~~~~~~~~~~~
>     .../mm/memory.c:4169:53: error: ‘MTHP_STAT_ANON_SWPIN_REFAULT’ undeclared (first use in this function)
>      4169 |                 count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>           |                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     .../mm/memory.c:4169:53: note: each undeclared identifier is reported only once for each function it appears in
>     cc1: some warnings being treated as errors
> 
> My kunit build config doesn't have CONFIG_TRANSPARE_HUGEPAGE.  Maybe that's the
> reason and this patch, or the patch that introduced the function and the enum
> need to take care of the case?

Hi SeongJae,
Thanks very much, can you check if the below fix the build? If yes, I will
include this fix while sending v3.

Subject: [PATCH] mm: fix build errors on CONFIG_TRANSPARENT_HUGEPAGE=N

Signed-off-by: Barry Song <v-songbaohua@oppo.com>
---
 mm/memory.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/memory.c b/mm/memory.c
index acc023795a4d..1d587d1eb432 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4142,6 +4142,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
 			&vmf->ptl);
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	/* We hit large folios in swapcache */
 	if (start_pte && folio_test_large(folio) && folio_test_swapcache(folio)) {
 		int nr = folio_nr_pages(folio);
@@ -4171,6 +4172,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	}
 
 check_pte:
+#endif
 	if (unlikely(!vmf->pte || !pte_same(ptep_get(vmf->pte), vmf->orig_pte)))
 		goto out_nomap;
Ryan Roberts April 11, 2024, 3:53 p.m. UTC | #3
On 09/04/2024 09:26, Barry Song wrote:
> From: Barry Song <v-songbaohua@oppo.com>
> 
> Currently, we are handling the scenario where we've hit a
> large folio in the swapcache, and the reclaiming process
> for this large folio is still ongoing.
> 
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> ---
>  include/linux/huge_mm.h | 1 +
>  mm/huge_memory.c        | 2 ++
>  mm/memory.c             | 1 +
>  3 files changed, 4 insertions(+)
> 
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index c8256af83e33..b67294d5814f 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -269,6 +269,7 @@ enum mthp_stat_item {
>  	MTHP_STAT_ANON_ALLOC_FALLBACK,
>  	MTHP_STAT_ANON_SWPOUT,
>  	MTHP_STAT_ANON_SWPOUT_FALLBACK,
> +	MTHP_STAT_ANON_SWPIN_REFAULT,

I don't see any equivalent counter for small folios. Is there an analogue?

>  	__MTHP_STAT_COUNT
>  };
>  
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index d8d2ed80b0bf..fb95345b0bde 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
>  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
>  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
>  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
> +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
>  
>  static struct attribute *stats_attrs[] = {
>  	&anon_alloc_attr.attr,
>  	&anon_alloc_fallback_attr.attr,
>  	&anon_swpout_attr.attr,
>  	&anon_swpout_fallback_attr.attr,
> +	&anon_swpin_refault_attr.attr,
>  	NULL,
>  };
>  
> diff --git a/mm/memory.c b/mm/memory.c
> index 9818dc1893c8..acc023795a4d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>  		nr_pages = nr;
>  		entry = folio->swap;
>  		page = &folio->page;
> +		count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);

I don't think this is the point of no return yet? There's the pte_same() check
immediately below (although I've suggested that needs to be moved to earlier),
but also the folio_test_uptodate() check. Perhaps this should go after that?

>  	}
>  
>  check_pte:
SeongJae Park April 11, 2024, 4:14 p.m. UTC | #4
Hi Barry,

On Thu, 11 Apr 2024 13:46:36 +1200 Barry Song <21cnbao@gmail.com> wrote:

> >> +		count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
> >>  	}
> >> 
> > From the latest mm-unstable tree, I get below kunit build failure and
> > 'git bisect' points this patch.
> > 
> >     $ ./tools/testing/kunit/kunit.py run --build_dir ../kunit.out/
> >     [16:07:40] Configuring KUnit Kernel ...
> >     [16:07:40] Building KUnit Kernel ...
> >     Populating config with:
> >     $ make ARCH=um O=../kunit.out/ olddefconfig
> >     Building with:
> >     $ make ARCH=um O=../kunit.out/ --jobs=36
> >     ERROR:root:.../mm/memory.c: In function ‘do_swap_page’:
> >     .../mm/memory.c:4169:17: error: implicit declaration of function ‘count_mthp_stat’ [-Werror=implicit-function-declaration]
> >      4169 |                 count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
> >           |                 ^~~~~~~~~~~~~~~
> >     .../mm/memory.c:4169:53: error: ‘MTHP_STAT_ANON_SWPIN_REFAULT’ undeclared (first use in this function)
> >      4169 |                 count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
> >           |                                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     .../mm/memory.c:4169:53: note: each undeclared identifier is reported only once for each function it appears in
> >     cc1: some warnings being treated as errors
> > 
> > My kunit build config doesn't have CONFIG_TRANSPARE_HUGEPAGE.  Maybe that's the
> > reason and this patch, or the patch that introduced the function and the enum
> > need to take care of the case?
> 
> Hi SeongJae,
> Thanks very much, can you check if the below fix the build? If yes, I will
> include this fix while sending v3.

Thank you for quick and kind reply :) I confirmed this fixes the build failure.

> 
> Subject: [PATCH] mm: fix build errors on CONFIG_TRANSPARENT_HUGEPAGE=N
> 
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
Tested-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

> ---
>  mm/memory.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index acc023795a4d..1d587d1eb432 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4142,6 +4142,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>  	vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
>  			&vmf->ptl);
>  
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  	/* We hit large folios in swapcache */
>  	if (start_pte && folio_test_large(folio) && folio_test_swapcache(folio)) {
>  		int nr = folio_nr_pages(folio);
> @@ -4171,6 +4172,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>  	}
>  
>  check_pte:
> +#endif
>  	if (unlikely(!vmf->pte || !pte_same(ptep_get(vmf->pte), vmf->orig_pte)))
>  		goto out_nomap;
>  
> -- 
> 2.34.1
> 
>
Barry Song April 11, 2024, 11:01 p.m. UTC | #5
On Fri, Apr 12, 2024 at 3:53 AM Ryan Roberts <ryan.roberts@arm.com> wrote:
>
> On 09/04/2024 09:26, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Currently, we are handling the scenario where we've hit a
> > large folio in the swapcache, and the reclaiming process
> > for this large folio is still ongoing.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > ---
> >  include/linux/huge_mm.h | 1 +
> >  mm/huge_memory.c        | 2 ++
> >  mm/memory.c             | 1 +
> >  3 files changed, 4 insertions(+)
> >
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index c8256af83e33..b67294d5814f 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -269,6 +269,7 @@ enum mthp_stat_item {
> >       MTHP_STAT_ANON_ALLOC_FALLBACK,
> >       MTHP_STAT_ANON_SWPOUT,
> >       MTHP_STAT_ANON_SWPOUT_FALLBACK,
> > +     MTHP_STAT_ANON_SWPIN_REFAULT,
>
> I don't see any equivalent counter for small folios. Is there an analogue?

Indeed, we don't count refaults for small folios, as their refault
mechanism is much
simpler compared to large folios. Implementing this counter can enhance the
system's visibility to users.

Personally, having this counter and observing a non-zero value greatly enhances
my confidence when debugging this refault series. Otherwise, it feels like being
blind to what's happening inside the system :-)

>
> >       __MTHP_STAT_COUNT
> >  };
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index d8d2ed80b0bf..fb95345b0bde 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
> >  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
> >  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
> >  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
> > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
> >
> >  static struct attribute *stats_attrs[] = {
> >       &anon_alloc_attr.attr,
> >       &anon_alloc_fallback_attr.attr,
> >       &anon_swpout_attr.attr,
> >       &anon_swpout_fallback_attr.attr,
> > +     &anon_swpin_refault_attr.attr,
> >       NULL,
> >  };
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 9818dc1893c8..acc023795a4d 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >               nr_pages = nr;
> >               entry = folio->swap;
> >               page = &folio->page;
> > +             count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>
> I don't think this is the point of no return yet? There's the pte_same() check
> immediately below (although I've suggested that needs to be moved to earlier),
> but also the folio_test_uptodate() check. Perhaps this should go after that?
>

swap_pte_batch() == nr_pages should have passed the test for pte_same.
folio_test_uptodate(folio)) should be also unlikely to be true as we are
not reading from swap devices for refault case.

but i agree we can move all the refault handling after those two "goto
out_nomap".

> >       }
> >
> >  check_pte:
>

Thanks
Barry
Huang, Ying April 17, 2024, 12:45 a.m. UTC | #6
Barry Song <21cnbao@gmail.com> writes:

> From: Barry Song <v-songbaohua@oppo.com>
>
> Currently, we are handling the scenario where we've hit a
> large folio in the swapcache, and the reclaiming process
> for this large folio is still ongoing.
>
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> ---
>  include/linux/huge_mm.h | 1 +
>  mm/huge_memory.c        | 2 ++
>  mm/memory.c             | 1 +
>  3 files changed, 4 insertions(+)
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index c8256af83e33..b67294d5814f 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -269,6 +269,7 @@ enum mthp_stat_item {
>  	MTHP_STAT_ANON_ALLOC_FALLBACK,
>  	MTHP_STAT_ANON_SWPOUT,
>  	MTHP_STAT_ANON_SWPOUT_FALLBACK,
> +	MTHP_STAT_ANON_SWPIN_REFAULT,

This is different from the refault concept used in other place in mm
subystem.  Please check the following code

	if (shadow)
		workingset_refault(folio, shadow);

in __read_swap_cache_async().

>  	__MTHP_STAT_COUNT
>  };

--
Best Regards,
Huang, Ying

> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index d8d2ed80b0bf..fb95345b0bde 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
>  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
>  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
>  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
> +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
>  
>  static struct attribute *stats_attrs[] = {
>  	&anon_alloc_attr.attr,
>  	&anon_alloc_fallback_attr.attr,
>  	&anon_swpout_attr.attr,
>  	&anon_swpout_fallback_attr.attr,
> +	&anon_swpin_refault_attr.attr,
>  	NULL,
>  };
>  
> diff --git a/mm/memory.c b/mm/memory.c
> index 9818dc1893c8..acc023795a4d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>  		nr_pages = nr;
>  		entry = folio->swap;
>  		page = &folio->page;
> +		count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>  	}
>  
>  check_pte:
Barry Song April 17, 2024, 1:16 a.m. UTC | #7
On Wed, Apr 17, 2024 at 8:47 AM Huang, Ying <ying.huang@intel.com> wrote:
>
> Barry Song <21cnbao@gmail.com> writes:
>
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > Currently, we are handling the scenario where we've hit a
> > large folio in the swapcache, and the reclaiming process
> > for this large folio is still ongoing.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > ---
> >  include/linux/huge_mm.h | 1 +
> >  mm/huge_memory.c        | 2 ++
> >  mm/memory.c             | 1 +
> >  3 files changed, 4 insertions(+)
> >
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index c8256af83e33..b67294d5814f 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -269,6 +269,7 @@ enum mthp_stat_item {
> >       MTHP_STAT_ANON_ALLOC_FALLBACK,
> >       MTHP_STAT_ANON_SWPOUT,
> >       MTHP_STAT_ANON_SWPOUT_FALLBACK,
> > +     MTHP_STAT_ANON_SWPIN_REFAULT,
>
> This is different from the refault concept used in other place in mm
> subystem.  Please check the following code
>
>         if (shadow)
>                 workingset_refault(folio, shadow);
>
> in __read_swap_cache_async().

right. it is slightly different as refault can also cover the case folios
have been entirely released and a new page fault happens soon
after it.
Do you have a better name for this?
MTHP_STAT_ANON_SWPIN_UNDER_RECLAIM
or
MTHP_STAT_ANON_SWPIN_RECLAIMING ?

>
> >       __MTHP_STAT_COUNT
> >  };
>
> --
> Best Regards,
> Huang, Ying
>
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index d8d2ed80b0bf..fb95345b0bde 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
> >  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
> >  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
> >  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
> > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
> >
> >  static struct attribute *stats_attrs[] = {
> >       &anon_alloc_attr.attr,
> >       &anon_alloc_fallback_attr.attr,
> >       &anon_swpout_attr.attr,
> >       &anon_swpout_fallback_attr.attr,
> > +     &anon_swpin_refault_attr.attr,
> >       NULL,
> >  };
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 9818dc1893c8..acc023795a4d 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >               nr_pages = nr;
> >               entry = folio->swap;
> >               page = &folio->page;
> > +             count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
> >       }
> >
> >  check_pte:
Huang, Ying April 17, 2024, 1:38 a.m. UTC | #8
Barry Song <21cnbao@gmail.com> writes:

> On Wed, Apr 17, 2024 at 8:47 AM Huang, Ying <ying.huang@intel.com> wrote:
>>
>> Barry Song <21cnbao@gmail.com> writes:
>>
>> > From: Barry Song <v-songbaohua@oppo.com>
>> >
>> > Currently, we are handling the scenario where we've hit a
>> > large folio in the swapcache, and the reclaiming process
>> > for this large folio is still ongoing.
>> >
>> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
>> > ---
>> >  include/linux/huge_mm.h | 1 +
>> >  mm/huge_memory.c        | 2 ++
>> >  mm/memory.c             | 1 +
>> >  3 files changed, 4 insertions(+)
>> >
>> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> > index c8256af83e33..b67294d5814f 100644
>> > --- a/include/linux/huge_mm.h
>> > +++ b/include/linux/huge_mm.h
>> > @@ -269,6 +269,7 @@ enum mthp_stat_item {
>> >       MTHP_STAT_ANON_ALLOC_FALLBACK,
>> >       MTHP_STAT_ANON_SWPOUT,
>> >       MTHP_STAT_ANON_SWPOUT_FALLBACK,
>> > +     MTHP_STAT_ANON_SWPIN_REFAULT,
>>
>> This is different from the refault concept used in other place in mm
>> subystem.  Please check the following code
>>
>>         if (shadow)
>>                 workingset_refault(folio, shadow);
>>
>> in __read_swap_cache_async().
>
> right. it is slightly different as refault can also cover the case folios
> have been entirely released and a new page fault happens soon
> after it.
> Do you have a better name for this?
> MTHP_STAT_ANON_SWPIN_UNDER_RECLAIM
> or
> MTHP_STAT_ANON_SWPIN_RECLAIMING ?

TBH, I don't think we need this counter.  It's important for you during
implementation.  But I don't think it's important for end users.

--
Best Regards,
Huang, Ying

>>
>> >       __MTHP_STAT_COUNT
>> >  };
>>
>> --
>> Best Regards,
>> Huang, Ying
>>
>> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> > index d8d2ed80b0bf..fb95345b0bde 100644
>> > --- a/mm/huge_memory.c
>> > +++ b/mm/huge_memory.c
>> > @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
>> >  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
>> >  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
>> >  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
>> > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
>> >
>> >  static struct attribute *stats_attrs[] = {
>> >       &anon_alloc_attr.attr,
>> >       &anon_alloc_fallback_attr.attr,
>> >       &anon_swpout_attr.attr,
>> >       &anon_swpout_fallback_attr.attr,
>> > +     &anon_swpin_refault_attr.attr,
>> >       NULL,
>> >  };
>> >
>> > diff --git a/mm/memory.c b/mm/memory.c
>> > index 9818dc1893c8..acc023795a4d 100644
>> > --- a/mm/memory.c
>> > +++ b/mm/memory.c
>> > @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> >               nr_pages = nr;
>> >               entry = folio->swap;
>> >               page = &folio->page;
>> > +             count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
>> >       }
>> >
>> >  check_pte:
Barry Song April 17, 2024, 1:48 a.m. UTC | #9
On Wed, Apr 17, 2024 at 1:40 PM Huang, Ying <ying.huang@intel.com> wrote:
>
> Barry Song <21cnbao@gmail.com> writes:
>
> > On Wed, Apr 17, 2024 at 8:47 AM Huang, Ying <ying.huang@intel.com> wrote:
> >>
> >> Barry Song <21cnbao@gmail.com> writes:
> >>
> >> > From: Barry Song <v-songbaohua@oppo.com>
> >> >
> >> > Currently, we are handling the scenario where we've hit a
> >> > large folio in the swapcache, and the reclaiming process
> >> > for this large folio is still ongoing.
> >> >
> >> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> >> > ---
> >> >  include/linux/huge_mm.h | 1 +
> >> >  mm/huge_memory.c        | 2 ++
> >> >  mm/memory.c             | 1 +
> >> >  3 files changed, 4 insertions(+)
> >> >
> >> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> >> > index c8256af83e33..b67294d5814f 100644
> >> > --- a/include/linux/huge_mm.h
> >> > +++ b/include/linux/huge_mm.h
> >> > @@ -269,6 +269,7 @@ enum mthp_stat_item {
> >> >       MTHP_STAT_ANON_ALLOC_FALLBACK,
> >> >       MTHP_STAT_ANON_SWPOUT,
> >> >       MTHP_STAT_ANON_SWPOUT_FALLBACK,
> >> > +     MTHP_STAT_ANON_SWPIN_REFAULT,
> >>
> >> This is different from the refault concept used in other place in mm
> >> subystem.  Please check the following code
> >>
> >>         if (shadow)
> >>                 workingset_refault(folio, shadow);
> >>
> >> in __read_swap_cache_async().
> >
> > right. it is slightly different as refault can also cover the case folios
> > have been entirely released and a new page fault happens soon
> > after it.
> > Do you have a better name for this?
> > MTHP_STAT_ANON_SWPIN_UNDER_RECLAIM
> > or
> > MTHP_STAT_ANON_SWPIN_RECLAIMING ?
>
> TBH, I don't think we need this counter.  It's important for you during
> implementation.  But I don't think it's important for end users.

Okay. If we can't find a shared interest between the
implementer and user, I'm perfectly fine with keeping it
local only for debugging purposes.

>
> --
> Best Regards,
> Huang, Ying
>
> >>
> >> >       __MTHP_STAT_COUNT
> >> >  };
> >>
> >> --
> >> Best Regards,
> >> Huang, Ying
> >>
> >> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> >> > index d8d2ed80b0bf..fb95345b0bde 100644
> >> > --- a/mm/huge_memory.c
> >> > +++ b/mm/huge_memory.c
> >> > @@ -556,12 +556,14 @@ DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
> >> >  DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
> >> >  DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
> >> >  DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
> >> > +DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
> >> >
> >> >  static struct attribute *stats_attrs[] = {
> >> >       &anon_alloc_attr.attr,
> >> >       &anon_alloc_fallback_attr.attr,
> >> >       &anon_swpout_attr.attr,
> >> >       &anon_swpout_fallback_attr.attr,
> >> > +     &anon_swpin_refault_attr.attr,
> >> >       NULL,
> >> >  };
> >> >
> >> > diff --git a/mm/memory.c b/mm/memory.c
> >> > index 9818dc1893c8..acc023795a4d 100644
> >> > --- a/mm/memory.c
> >> > +++ b/mm/memory.c
> >> > @@ -4167,6 +4167,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> >> >               nr_pages = nr;
> >> >               entry = folio->swap;
> >> >               page = &folio->page;
> >> > +             count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
> >> >       }
> >> >
> >> >  check_pte:
diff mbox series

Patch

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index c8256af83e33..b67294d5814f 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -269,6 +269,7 @@  enum mthp_stat_item {
 	MTHP_STAT_ANON_ALLOC_FALLBACK,
 	MTHP_STAT_ANON_SWPOUT,
 	MTHP_STAT_ANON_SWPOUT_FALLBACK,
+	MTHP_STAT_ANON_SWPIN_REFAULT,
 	__MTHP_STAT_COUNT
 };
 
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d8d2ed80b0bf..fb95345b0bde 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -556,12 +556,14 @@  DEFINE_MTHP_STAT_ATTR(anon_alloc, MTHP_STAT_ANON_ALLOC);
 DEFINE_MTHP_STAT_ATTR(anon_alloc_fallback, MTHP_STAT_ANON_ALLOC_FALLBACK);
 DEFINE_MTHP_STAT_ATTR(anon_swpout, MTHP_STAT_ANON_SWPOUT);
 DEFINE_MTHP_STAT_ATTR(anon_swpout_fallback, MTHP_STAT_ANON_SWPOUT_FALLBACK);
+DEFINE_MTHP_STAT_ATTR(anon_swpin_refault, MTHP_STAT_ANON_SWPIN_REFAULT);
 
 static struct attribute *stats_attrs[] = {
 	&anon_alloc_attr.attr,
 	&anon_alloc_fallback_attr.attr,
 	&anon_swpout_attr.attr,
 	&anon_swpout_fallback_attr.attr,
+	&anon_swpin_refault_attr.attr,
 	NULL,
 };
 
diff --git a/mm/memory.c b/mm/memory.c
index 9818dc1893c8..acc023795a4d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4167,6 +4167,7 @@  vm_fault_t do_swap_page(struct vm_fault *vmf)
 		nr_pages = nr;
 		entry = folio->swap;
 		page = &folio->page;
+		count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
 	}
 
 check_pte: