Re: [00/17] Large Blocksize Support V3

[David Chinner <dgc@sgi.com>]

On Fri, Apr 27, 2007 at 12:26:40AM -0700, Andrew Morton wrote:
> On Fri, 27 Apr 2007 00:19:49 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:
> 
> > The page cache handling in the various layers is significantly 
> > simplified which reduces maintenance cost.
> 
> How on earth can the *addition* of variable pagecache size simplify the
> existing code?
> 
> What cleanups are in this patchset which cannot be made *without* the
> addition of variable pagecache size?

Sure they can - but then the variable size page cache becomes even
more trivial to implement. ;)

> > Dave, where are we with the performance tests?
> 
> Well yes.

Backed up behind real work. :/

Hopefully I'll have something tonight from my small test box.
it'll be some time next week before I get a chance to do anything
on a hardware raid array.

> Do note that if the numbers are good, we also need to look at how generally
> useful this work is.  For example, if it only benefits one particular
> arguably-crippled present-generation adapter then that of course weakens the
> case.

I think you mistook my "hw RAID" as a "HW RAID adapter". I was
talking about "HW RAID arrays" as in rack mounted controllers on the
other end of multiple FC HCAs.

What I'm talking about is the difference in perfomrance when we can
do large enough I/Os to be able to do full-stripe writes on this
sort of hardware.  Modern HW raid arrays go much faster when you do
aligned, full-stripe width writes and right now x86_64 linux is
not able to do this....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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/