Re: [00/17] Large Blocksize Support V3

[Christoph Lameter]

On Thu, 26 Apr 2007, Eric W. Biederman wrote:

> My most practical suggestion is to have support code so that you can
> do all of the locking (that I/O cares about) on the first page of a
> page group in the page cache.  You don't need larger physical pages to
> do that.

Virtual mappings for larger pages? Or some software simulated form? This 
all sounds like awful hacks.

> Iff we really the larger physical page size to support the hardware
> then it makes sense to go down a path of larger pages.  But it doesn't.

You are redefining the problem. We need larger physical sizes to support 
the hardware. Yes. We can dodge the issue with shim layers and hacks. It 
is obvious from the kernel sources that this is needed.
  
> There is also a more fundamental reasons this patch is silly.  It assumes
> that there is a trivial mapping between filesystems (the primary target
> of the page cache and blocks on disk).  Now I admit this is common but
> there is no reason to supposed it is true, and this patch appears to
> exacerbate things.

The patch does the obvious... Nothing is silly about memory being 
contigous in memory and on disk.
-
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/