Re: [PATCH 06/43] FS-Cache: Recruit a couple of page flags for cache management [ver #46]

[David Howells]

Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:

> Haven't looked closely at how fscache works.

It's fairly simple.  FS-Cache sets PG_private_2 (PageFsCache) on pages that the
netfs tells it about, if it retains an interest in the page.  This causes
invalidatepage() and suchlike to be invoked on that page when the page is
discarded.

The netfs can check for the page being in use by calling PageFsCache() and then
uncache the page if it is in use:

	#ifdef CONFIG_AFS_FSCACHE
		if (PageFsCache(page)) {
			struct afs_vnode *vnode = AFS_FS_I(page->mapping->host);
			wait_on_page_fscache_write(page);
			fscache_uncache_page(vnode->cache, page);
		}
	#endif

which clears the bit.

Furthermore, when FS-Cache is asked to store a page to the cache, it
immediately marks it with PG_owner_priv_2 (PageFsCacheWrite).  This is cleared
when FS-Cache no longer needs the data in the page for writing to the cache.

This allows (1) invalidatepage() to wait until the page is written before it is
returned to the memory allocator, and (2) releasepage() to indicate that the
page is busy if __GFP_WAIT is not given.

> Possibly you can't reuse mappedtodisk....

PG_mappedtodisk has a very specific meaning to fs/buffer.c and fs/mpage.c.  I
can't also easily make it mean that a page is backed by the cache.  A page can
be cached and not mapped to disk.

> > We still need a way of triggering the page invalidation callbacks for in-use
> > pages, however.  PG_private, as I've said, is not currently a viable option.
> 
> Can you say exactly why not?

fs/buffer.c owns PG_private in filesystems that use standard buffering.  It
sets it, clears it and tests it at its own behest without recourse to the
filesystem using it.

ISO9660 uses fs/buffer.c.

I want to get ISO9660 to use FS-Cache.

Also NFS uses PG_private for its own nefarious purposes.  Making PG_private be
the conjunction of both purposes entailed some fairly messy patching.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/