lkml.org 
[lkml]   [2007]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [00/17] Large Blocksize Support V3
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@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-04-26 20:05    [W:0.336 / U:21.936 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site