Messages in this thread | | | Date | Thu, 26 Apr 2007 19:53:57 -0700 | From | Andrew Morton <> | Subject | Re: [00/17] Large Blocksize Support V3 |
| |
On Fri, 27 Apr 2007 12:27:31 +1000 David Chinner <dgc@sgi.com> wrote:
> On Thu, Apr 26, 2007 at 07:04:38PM -0700, Andrew Morton wrote: > > On Tue, 24 Apr 2007 15:21:05 -0700 clameter@sgi.com wrote: > > > > > This patchset modifies the Linux kernel so that larger block sizes than > > > page size can be supported. Larger block sizes are handled by using > > > compound pages of an arbitrary order for the page cache instead of > > > single pages with order 0. > > > > Something I was looking for but couldn't find: suppose an application takes > > a pagefault against the third 4k page of an order-2 pagecache "page". We > > need to instantiate a pte against find_get_page(offset/4)+3. But these > > patches don't touch mm/memory.c at all and filemap_nopage() appears to > > return the zeroeth 4k page all the time in that case. > > > > So.. what am I missing, and how does that part work? > > "mmap not supported yet" ;)
erk. I suspect this will have its sticky paws all over core mm.
> > Also, afaict your important requirements would be met by retaining > > PAGE_CACHE_SIZE=4k and simply ensuring that pagecache is populated by > > physically contiguous pages > > Sure, that addresses the larger I/O side of things, but it doesn't address > the large filesystem blocksize issues that can only be solved with some kind > of page aggregation abstraction.
a) That wasn't a part of Christoph's original rationale list, so forgive me for thinking it is not so important and got snuck in post-facto when things got tough.
b) I don't immediately see why a filesystam cannot implement larger blocksizes via this scheme - instantiate and lock four pages and go for it.
> Compound pages and high order page cache > indexing solves this extremely neatly, regardless of whether the compound > page is contiguous or not.....
We cannot say anything about neatness until we've seen mmap. - 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/
| |