David Howells <dhowells@xxxxxxxxxx> 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
