Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> And as far as I can tell, fscache doesn't want that PG_private_2 bit
> to interact with the random VM lifetime or migration rules either, and
> should rely entirely on the page count. David?
It's slightly complicated for fscache as there are two separate pieces of code
involved:
(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()).
(2) For the new netfs lib, PG_fscache is ignored by fscache itself and is
used by the read helpers. The helpers simply use it analogously to
PG_writeback, indicating that there's I/O in progress from this page to
the cache[*]. It's fine to take a ref here because we know we'll drop it
shortly.
Here PG_fscache might prevent page eviction or migration, but only
because I/O is in progress. If an increment on the page refcount
suffices, that's fine.
In both cases, releasepage, etc. look at PG_fscache and decide whether to wait
or not (releasepage may tell the caller to skip the page if PG_fscache is
set).
[*] Willy suggested using PG_writeback to cover both write to the server and
write to the cache, and getting rid of PG_fscache entirely, but that would
require extra mechanisms. There are three cases:
(a) We might be writing to only the cache, e.g. because we just read from the
server.
Note that this may adversely affect code that does accounting associated
with PG_writeback because we woudn't actually be writing back a user-made
change or dealing with a dirty page. I'm not sure if that's an issue.
(b) We might writing to both, in which case we can expect both writes to
finish at different times.
(c) We might only be writing to the server, e.g. because there's no space in
the cache or there is no cache.
It's something that might make sense, however, and we can look at in the
future, but for the moment having two separate page flags is simplest.
An additional use of PG_fscache is to prevent a second write to the cache from
being started whilst one is in progress. I guess that would be taken over by
PG_writeback if we used that.
David
