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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ttcdz3y1.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Tue, 12 Nov 2024 08:33:10 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org,  linux-kernel@...r.kernel.org,
  akpm@...ux-foundation.org,  david@...hat.com,  nphamcs@...il.com,
  nehagholkar@...a.com,  abhishekd@...a.com,  Johannes Weiner
 <hannes@...xchg.org>,  Feng Tang <feng.tang@...el.com>
Subject: Re: [PATCH 0/3] mm,TPP: Enable promotion of unmapped pagecache

Gregory Price <gourry@...rry.net> writes:

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