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: <20070428143753.GV19966@holomorphy.com>
Date:	Sat, 28 Apr 2007 07:37:53 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	David Chinner <dgc@....com>,
	Christoph Lameter <clameter@....com>,
	linux-kernel@...r.kernel.org, Mel Gorman <mel@...net.ie>,
	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 Sat, Apr 28, 2007 at 12:29:08PM +0100, Alan Cox wrote:
> Not neccessarily. If you use 16K contiguous pages you have to do
> more work to get memory contiguously and you have less cache efficiency
> both of which will do serious damage to performance with poor I/O
> subsystems for all the extra paging and I/O, and probably way more than
> sglist stuff on PC class boxes. (yes its probably a win on your 32GB SGI
> monster)

Some of this happens anyway with readahead window sizes and the like.
jejb's also seen gains from my fiddling with mm/page_alloc.c so that
pages come out in the right order (which has since regressed and they
don't anymore; odds are s/list_add/list_add_tail/ in one or two places
will fix it), though that didn't involve crappy controllers.

It may be that readahead needs to be less aggressive for PC class boxes,
but I expect that's already been dealt with.

On Sat, Apr 28, 2007 at 12:29:08PM +0100, Alan Cox wrote:
> That aside you are improving things for most but not all half-assed
> controllers (some sglists are simply page pointers for each 4K page or
> have different efficient encoding for page sized chunks (I2O). If you are
> reading large chunks on a really crap controller (eg IDE in PIO) then the
> fact you pull 16K when you need 4K will also wipe out any gains.

Sorry about the "back to basics" bit here, but...

It might help me to follow the discussion if what's meant by a "crappy
controller" could be clarified. The notion I had in mind to date was
poor or absent support for scatter gather, where deficiencies can take
the form of limited sglist element size, limited sglist length, or gross
inefficiency in processing large sglists (e.g. implemented internally as
a series of requests, one for each sglist element).

I would think that the gains from cramming larger amounts of data into
an individual command would largely be due to avoiding artificially
serializing IO so the speedup comes about from concurrent processing of
the IO within the controller or disk as opposed to, say, reducing the
overhead of issuing commands. Maybe clarifying why we expect larger IO's
to be faster would help, too.

Those clarifications might help more precisely define what issue all
this is meant to address.

-- wli
-
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/