linux-kernel - Re: [00/17] Large Blocksize Support V3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704272158360.7342@schroedinger.engr.sgi.com>
Date:	Fri, 27 Apr 2007 22:08:17 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>,
	William Lee Irwin III <wli@...omorphy.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Nick Piggin <nickpiggin@...oo.com.au>
Subject: Re: [00/17] Large Blocksize Support V3

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/