Re: [PATCH RFC] mm: madvise: pageout: ignore references rather than clearing young

[SeongJae Park]

On Sun, 25 Feb 2024 04:33:25 +0800 Barry Song <21cnbao@xxxxxxxxx> wrote:

> On Sun, Feb 25, 2024 at 4:12 AM SeongJae Park <sj@xxxxxxxxxx> wrote:
> >
> > On Sat, 24 Feb 2024 11:07:23 -0800 SeongJae Park <sj@xxxxxxxxxx> wrote:
> >
> > > Hi Barry,
> > >
> > > On Sat, 24 Feb 2024 12:37:59 +0800 Barry Song <21cnbao@xxxxxxxxx> wrote:
> > >
> > > [...]
> > > >
> > > > BTW\uff0c
> > > > Hi SeongJae,
> > > > I am not quite sure if damon also needs this, so I have kept damon as is by
> > > > setting ignore_references = false.  MADV_PAGEOUT is an explicit hint users
> > > > don't want the memory to be reclaimed, I don't know if it is true for damon as
> > > > well. If you have some comments, please chime in.
> > >
> > > Thank you for calling my name :)
> > >
> > > For DAMON's usecase, the document simply says the behavior would be same to
> > > MADV_PAGEOUT, so if we conclude to change MADV_PAGEOUT, I think same change
> > > should be made for DAMON's usecase, or update DAMON document.
> >
> > Thanks to Barry's nice explanation on my other reply to the patch, now I think
> > the change is modest, and therefore I'd prefer the first way: Changing DAMON's
> > usecase, and keep the document as is.
> 
> Hi SeongJae,
> 
> thanks! I actually blindly voted for keeping DAMON's behaviour but
> slightly updated the
> document as I set ignore_references to false for the DAMON case in the RFC :-)
> 
> --- a/mm/damon/paddr.c
> +++ b/mm/damon/paddr.c
> @@ -249,7 +249,7 @@ static unsigned long damon_pa_pageout(struct
> damon_region *r, struct damos *s)
>  put_folio:
>   folio_put(folio);
>   }
> - applied = reclaim_pages(&folio_list);
> + applied = reclaim_pages(&folio_list, false);
>   cond_resched();
>   return applied * PAGE_SIZE;
>  }
> 
> MADV_PAGEOUT comes from userspace by a specific process to tell the kernel
> to reclaim its own memory(actually focus on non-shared memory as it
> skips folios with
> mapcount>1).
> The range is a virtual address and the app does know it doesn't want
> to access the
> range in the foreseeable future.  and the affected app is itself not global.
> 
> In the DAMON case,  it seems the range is the physical address.  if
> the pa is mapped
> by more than one process, it seems safer to double-check in the kernel
> as it might
> affect multiple processes?
> 
> Please correct me if I am wrong.

You're correct.  Please consider below in my previous reply[1] as my opinion.

    let's keep the change for paddr.c in your patch as is.

[1] https://lore.kernel.org/r/20240224205453.47096-1-sj@xxxxxxxxxx


Thanks,
SJ

> 
> >
> >
> > Thanks,
> > SJ
> >
> > >
> > >
> > > Thanks,
> > > SJ
> 
> Thanks
>  Barry