On Thu, Nov 15, 2007 at 12:15:41PM +0000, David Howells wrote: > Nick Piggin <npiggin@xxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
