Gregory Price <gourry@xxxxxxxxxx> writes: > On Mon, Nov 11, 2024 at 09:35:09AM +0800, Huang, Ying wrote: >> Gregory Price <gourry@xxxxxxxxxx> 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
