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/