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

["Huang, Ying" <ying.huang@intel.com>]

Gregory Price <gourry@gourry.net> writes:

> 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

We can ignore kthread when collecting promoting candidates folios.

> going to try task_work first.

--
Best Regards,
Huang, Ying