On Fri, 27 Apr 2007, Andrew Morton wrote:
> My (repeated) point is that if we populate pagecache with physically-contiguous 4k
> pages in this manner then bio+block will be able to create much larger SG lists.
True but the "if" becomes exceedingly rare the longer the system was in
operation. 64k implies 16 pages in sequence. This is going to be a bit
difficult to get. Then there is the overhead of handling these pages.
Which may be not significant given growing processor capabilities in some
usage cases. In others like a synchronized application running on a large
number of nodes this is likely introduce random delays between processor
to processor communication that will significantly impair performance.
And then there is the long list of features that cannot be accomplished
with such an approach like mounting a volume with large block size,
handling CD/DVDs, getting rid of various shim layers etc.
I'd also like to have much higher orders of allocations for scientific
applications that require an extremely large I/O rate. For those we
could f.e. dedicate memory nodes that will only use a very high page
order to prevent fragmentation. E.g. 1G pages is certainly something that
lots of our customers would find beneficial (and they are actually
already using those types of pages in the form of huge pages but with
limited capabilities).
But then we are sadly again trying to find another workaround that
will not get us there and will not allow the flexibility in the
VM that would make things much easier for lots of usage scenarios.
-
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]
