Re: [00/17] Large Blocksize Support V3 (mmap conceptual discussion)

[Christoph Lameter]

On Thu, 26 Apr 2007, Andrew Morton wrote:

> > 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.

It was definitely part of my thinking. I never thought anyone could do it 
differently so I did not emphasize it.
 
> 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.

Rough Draft was posted at 
http://marc.info/?l=linux-kernel&m=117709695522443&w=2
http://marc.info/?l=linux-kernel&m=117709215016822&w=2
http://marc.info/?l=linux-kernel&m=117709238129124&w=2

Basically 4k mmap semantics are preserved. One can mmap any 4k section of 
a compound page. state information is kept in the head page. So we have two
page struct pointers to juggle

1. The one pointing to the page for address calculations COW etc.

2. The one pointing to the head page for state information.

For each 4k pointer from a process to a compound page we would 
have to take a refcount.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/