lkml.org 
[lkml]   [2021]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v4 02/28] mm: Add an unlock function for PG_private_2/PG_fscache
Date
David Howells <dhowells@redhat.com> wrote:

> (1) For the old fscache code that I'm trying to phase out, it does not take a
> ref when PG_fscache is taken (probably incorrectly), relying instead on
> releasepage, etc. getting called to strip the PG_fscache bit. PG_fscache
> is held for the lifetime of the page, indicating that fscache knows about
> it and might access it at any time (to write to the cache in the
> background for example or to move pages around in the cache).
>
> Here PG_fscache should not prevent page eviction or migration and it's
> analogous to PG_private.
>
> That said, the old fscache code keeps its own radix trees of pages that
> are undergoing write to the cache, so to allow a page to be evicted,
> releasepage and co. have to consult those
> (__fscache_maybe_release_page()).

Note that, ideally, we'll be able to remove the old fscache I/O code in the
next merge window or the one after.

David

\
 
 \ /
  Last update: 2021-03-17 11:55    [W:0.111 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site