Messages in this thread | | | Date | Tue, 11 Sep 2007 17:04:41 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: [00/41] Large Blocksize Support V7 (adds memmap support) |
| |
On Wed, 12 Sep 2007, Andrea Arcangeli wrote:
> On Tue, Sep 11, 2007 at 01:41:08PM -0700, Christoph Lameter wrote: > > The advantages of this approach over Andreas is basically that the 4k > > filesystems still can be used as is. 4k is useful for binaries and for > > If you mean that with my approach you can't use a 4k filesystem as is, > that's not correct. I even run the (admittedly premature but > promising) benchmarks on my patch on a 4k blocksized > filesystem... Guess what, you can even still mount a 1k fs on a 2.6 > kernel.
Right you can use a 4k filesystem. The 4k blocks are buffers in a larger page then.
> The main advantage I can see in your patch is that distributions won't > need to ship a 64k PAGE_SIZE kernel rpm (but your single rpm will be > slower).
I would think that your approach would be slower since you always have to populate 1 << N ptes when mmapping a file? Plus there is a lot of wastage of memory because even a file with one character needs an order N page? So there are less pages available for the same workload.
Then you are breaking mmap assumptions of applications becaused the order N kernel will no longer be able to map 4k pages. You likely need a new binary format that has pages correctly aligned. I know that we would need one on IA64 if we go beyond the established page sizes. - 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/
| |