DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.au;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id;
  b=cPxgpOtgCZ0MImLRNz4cVRUwmd1y9xVGRPTFnMiNp4g9M2OLCqZoAOwD64wPaTxSW829yanSmdUqAPl/nCK+KRgB53g313TpcJJuFTF4GooHWDgeFYkqUwxJVwg2Qh/1Rq/AqvRBCG8Fca2nHL/NKh6qro6DY5nauDEWKNcCJlI=  ;
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: David Howells <dhowells@redhat.com>
Subject: Re: [PATCH 06/41] FS-Cache: Recruit a page flags for cache management [ver #48]
Date: Sat, 4 Apr 2009 17:04:49 +1100
User-Agent: KMail/1.9.51 (KDE/4.0.4; ; )
Cc: linux-kernel@vger.kernel.org, nfsv4@linux-nfs.org,
       linux-fsdevel@vger.kernel.org
References: <20090403155436.28714.23368.stgit@warthog.procyon.org.uk> <20090403155507.28714.13233.stgit@warthog.procyon.org.uk>
In-Reply-To: <20090403155507.28714.13233.stgit@warthog.procyon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200904041704.49584.nickpiggin@yahoo.com.au>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1217
Lines: 31

And frame changelogs like this as what the patch is actually doing.

mm: add another page bit to signal fs private data

Add a new flag PG_private_2 which, similarly to PG_private, instructs
the mm to call into the fs when releasing or invalidating the page.

fscache will use this for blah blah blah.


> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -283,7 +283,7 @@ static inline int page_mapping_inuse(struct page *page)
>  
>  static inline int is_page_cache_freeable(struct page *page)
>  {
> -	return page_count(page) - !!PagePrivate(page) == 2;
> +	return page_count(page) - !!page_has_private(page) == 2;
>  }
>  
>  static int may_write_to_queue(struct backing_dev_info *bdi)

What if the page has both private bits set? Will this count for 2 references?
If not, that's unintuitive and needs commenting somewhere so nobody else who
might use this bit will end up with memory leaks. If so, then you need to
modify this check to account for both possible references.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/