Re: [PATCH 0/3] mm,TPP: Enable promotion of unmapped pagecache

[Gregory Price <gourry@gourry.net>]

On Mon, Nov 11, 2024 at 09:35:09AM +0800, Huang, Ying wrote:
> Gregory Price <gourry@gourry.net> writes:
> 
> >
> > Exploring and testing this a little further, I brought this up to current
> > folio work in 6.9 and found this solution to be unstable as-is.
> >
> > After some work to fix lock/reference issues, Johannes pointed out that
> > __filemap_get_folio can be called from an atomic context - which means it
> > may not be safe to do migrations in this context.
> 
> Sorry, I don't understand this, the above patch changes
> filemap_get_pages() and grab_cache_page_write_begin() instead of
> __filemap_get_folio().
>

on newer kernels, grab_cache_page_write_begin is a compat wrapper for
__filemap_get_folio and folio_file_page.  This chunk of code has changed
somewhat significantly, actually.
 
> > We're back to looking at something like an LRU-esque system, but now we're
> > thinking about isolating the folios in folio_mark_accessed into a task-local
> > list, and then process the list on resume.
> 
> If necessary, we can use a similar method for above solution too.  And
> we can filter accessed once folios with folio_mark_accessed() firstly.
> That is, only promote a page if,
> 
> - record the folio access time in folio_mark_accessed() only
> - when the folio are accessed again, and "access_time - record_time <
>   threshold", promote the folio.
> 

yes this was the thought.

> > Basically we're thinking
> >
> > 1) hook folio_mark_accessed and use PG_ACTIVE/PG_ACCESSED to determine whether
> >    the page is a promotion candidate.
> > 2) if it is, isolate it from the LRU - which is safe because folio_mark_accessed
> >    already does this elsewhere, and place it onto current->promo_queue
> > 3) set_notify_resume
> > 4) add logic to resume_user_mode_work() to run through current->promo_queue and
> >    either promote the pages accordingly, or do folio_putback_lru on failure.
> 
> Use a task_work?
> 

probably more correct, had a discussion about kernel threads accessing
file cache and we weren't sure if that situation even existed - so probably
going to try task_work first.

~Gregory