From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH 02/14] FS-Cache: Recruit a couple of page flags for cache management Date: Wed, 01 Aug 2007 09:27:13 +0100 Message-ID: <17631.1185956833@redhat.com> References: <1185949055.12034.31.camel@twins> <20070731202454.6412.88646.stgit@warthog.cambridge.redhat.com> <20070731202505.6412.37918.stgit@warthog.cambridge.redhat.com> Reply-To: Linux filesystem caching discussion list Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, nfsv4@linux-nfs.org, trond.myklebust@fys.uio.no, torvalds@osdl.org, linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org To: Peter Zijlstra Return-path: In-Reply-To: <1185949055.12034.31.camel@twins> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cachefs-bounces@redhat.com Errors-To: linux-cachefs-bounces@redhat.com List-Id: linux-fsdevel.vger.kernel.org Peter Zijlstra wrote: > Not sure its a good idea to overload page_has_private() with an > overloadable page-flag. What if some future FS wants to use > PG_owner_priv_2 for other purposes? All that it means is that releasepage() and co will get called if a page is to be released or invalidated that has that bit set. I think that's something a future FS could probably live with. However, I do have to trigger a call to releasepage() and co *somehow*. > Obviously filesystems cannot use these two page-flags if they want to be > compatible with FS-cache, but need all filesystems be? What do you mean? That's why I went for the PG_owner_priv_* approach rather than just naming the bits unto FS-Cache directly. > (also, ouch! - 2 pageflags) Yeah. The consequence of having things asynchronous is that you have to find signalling mechanisms to synchronise around the asynchronicity:-/ Furthermore, it occurs to me that I can't use PG_private or page->private to store this information because I want to make isofs use caching, and those two pieces of information are owned by the buffering code. David