linux-kernel - Re: [dm-devel] [PATCH v4 01/11] block: make generic_make

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: <20150527004022.GD31182@agk-dp.fab.redhat.com>
Date:	Wed, 27 May 2015 01:40:22 +0100
From:	Alasdair G Kergon <agk@...hat.com>
To:	device-mapper development <dm-devel@...hat.com>
Cc:	Alasdair G Kergon <agk@...hat.com>,
	Mike Snitzer <snitzer@...hat.com>,
	Ming Lei <ming.lei@...onical.com>, Al@...hat.com,
	Christoph Hellwig <hch@....de>,
	Lars Ellenberg <drbd-dev@...ts.linbit.com>, Oleg@...hat.com,
	Philip Kelleher <pjk1939@...ux.vnet.ibm.com>,
	Joshua Morris <josh.h.morris@...ibm.com>,
	Christoph Hellwig <hch@...radead.org>, Kent@...hat.com,
	Overstreet <kent.overstreet@...il.com>,
	Nitin Gupta <ngupta@...are.org>,
	Drokin <oleg.drokin@...el.com>, Viro <viro@...iv.linux.org.uk>,
	Dave Chinner <dchinner@...hat.com>, Ming Lin <mlin@...nel.org>,
	Jens Axboe <axboe@...nel.dk>,
	Andreas Dilger <andreas.dilger@...el.com>,
	Geoff Levand <geoff@...radead.org>,
	Jiri Kosina <jkosina@...e.cz>,
	lkml <linux-kernel@...r.kernel.org>, Jim Paris <jim@...n.com>,
	Minchan Kim <minchan@...nel.org>,
	Dongsu Park <dpark@...teo.net>, drbd-user@...ts.linbit.com
Subject: Re: [dm-devel] [PATCH v4 01/11] block: make generic_make_request
	handle arbitrarily sized bios

On Wed, May 27, 2015 at 09:06:40AM +1000, Neil Brown wrote:
> Because we don't know what the "right" size is.  And the "right" size can
> change when array reconfiguration happens.

In certain configurations today, device-mapper does report back a sensible
maximum bio size smaller than would otherwise be used and thereby avoids
retrospective splitting.  (In tests, the overhead of the duplicate calculation
was found to be negligible so we never restructured the code to optimise it away.)

> Splitting has to happen somewhere, if only in bio_addpage where it decides to
> create a new bio rather than add another page to the current one.  So moving
> the split to a different level of the stack shouldn't necessarily change the
> performance profile.

It does sometimes make a significant difference to device-mapper stacks.
DM only uses it for performance reasons - it can already split bios when
it needs to.  I tried to remove merge_bvec_fn from DM several years ago but
couldn't because of the adverse performance impact of lots of splitting activity.

The overall cost of splitting ought to be less in many (but not necessarily
all) cases now as a result of all these patches, so exactly where the best
balance lies now needs to be reassessed empirically.  It is hard to reach
conclusions theoretically because of the complex interplay between the various
factors at different levels.

Alasdair

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