Re: [rfc][patch 3/5] afs: new aops

[Nick Piggin <npiggin@suse.de>]

On Thu, Nov 15, 2007 at 12:15:41PM +0000, David Howells wrote:
> Nick Piggin <npiggin@suse.de> wrote:
> 
> > > So you're saying a struct page controls an area of PAGE_CACHE_SIZE, not an
> > > area of PAGE_SIZE?
> > 
> > No, a pagecache page is PAGE_CACHE_SIZE.
> 
> That doesn't answer my question.  I didn't ask about 'pagecache pages' per se.
> 
> Are you saying then that a page struct always represents an area of PAGE_SIZE
> to, say, the page allocator and PAGE_CACHE_SIZE to a filesystem's address
> operations?

Yes.

 
> How about I state it this way: Please define what the coverage of a
> (non-compound) struct page is, and how this relates to PAGE_SIZE and
> PAGE_CACHE_SIZE.  If it's well-defined then this cannot be hard, right?
 
No it's easy. It's PAGE_SIZE (which also happens to be PAGE_CACHE_SIZE).
An implementation that would (not trivially, but without changing the
basic concepts) allow a larger pagecache size is with compound pages. And
actually hugetlbfs already does this.


> > And not all struct pages control the same amount of data anyway, with
> > compound pages.
> 
> Compound pages are irrelevant to my question.  A compound page is actually a
> regulated by a series of page structs, each of which represents a 'page' of
> real memory.

And it can also represent a PAGE_CACHE_SIZE page of pagecache.
 

> Do you say, then, that all, say, readpage() and readpages() methods must
> handle a compound page if that is given to them?

I'm not talking about a specific implementation that allows
PAGE_CACHE_SIZE > PAGE_SIZE. So no, I don't say anything about that. I
say that pagecache pages are PAGE_CACHE_SIZE! Yes it is easy now because
that is the same as PAGE_SIZE. Yes it will be harder if you wanted to
change that. What you would not have to change is the assumption that
pagecache pages are in PAGE_SIZE units.