lkml.org 
[lkml]   [2007]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-09-12 02:07    [W:0.581 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site