| 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
| ||
|
Message-ID: <20070426174254.GD2017@kernel.dk> Date: Thu, 26 Apr 2007 19:42:54 +0200 From: Jens Axboe <jens.axboe@...cle.com> To: Nick Piggin <nickpiggin@...oo.com.au> Cc: David Chinner <dgc@....com>, Christoph Lameter <clameter@....com>, "Eric W. Biederman" <ebiederm@...ssion.com>, linux-kernel@...r.kernel.org, Mel Gorman <mel@...net.ie>, William Lee Irwin III <wli@...omorphy.com>, Badari Pulavarty <pbadari@...il.com>, Maxim Levitsky <maximlevitsky@...il.com> Subject: Re: [00/17] Large Blocksize Support V3 On Fri, Apr 27 2007, Nick Piggin wrote: > Why do we limit drivers to 128 sg entries? No particular reason, except than to avoid 2^bigger order allocations. 2MiB requests would require 3 contig pages to setup the sg list, which is (probably) a little troublesome especially since it's sometimes atomically allocated. Larger pages are by no means a prerequisite to getting larger requests, assuming your hardware can handle the bigger sglist. There are other ways of doing that, I've contemplated doing chained sglists and adding sg_for_each_segment() macros for iterating these things. Drivers that want larger sglists would then be required to update their sg mapping loop to use the provided macros. It wouldn't be too hard. -- Jens Axboe - 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/
Powered by blists - more mailing lists