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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
