linux-kernel - Re: [PATCH v5 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 for Android: free password hash cracker in your pocket

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

Message-ID: <yq1k2t3gkq3.fsf@sermon.lab.mkp.net>
Date:	Mon, 10 Aug 2015 12:40:52 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Ming Lin <mlin@...nel.org>
Cc:	Mike Snitzer <snitzer@...hat.com>, axboe@...com,
	Christoph Hellwig <hch@...radead.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	device-mapper development <dm-devel@...hat.com>,
	Ming Lei <ming.lei@...onical.com>,
	Christoph Hellwig <hch@....de>,
	Alasdair Kergon <agk@...hat.com>,
	Lars Ellenberg <drbd-dev@...ts.linbit.com>,
	Philip Kelleher <pjk1939@...ux.vnet.ibm.com>,
	Kent Overstreet <kent.overstreet@...il.com>,
	Nitin Gupta <ngupta@...are.org>,
	Ming Lin <ming.l@....samsung.com>,
	Oleg Drokin <oleg.drokin@...el.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	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,
	Joe Thornber <ejt@...hat.com>
Subject: Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios

>>>>> "Ming" == Ming Lin <mlin@...nel.org> writes:

Ming,

Ming> I also prefer using MAX_BIO_SECTORS.  Otherwise, we may have non
Ming> page size aligned splits.

This does not matter for write same and discard since there is only a
single logical block of payload. Also, given limitations in SATA we're
always issuing 2GB-32KB sized discards. Rounding those down to an even
1GB would impact performance.

I am sympathetic to wanting to issue I/Os that are aligned to powers of
two. But for most devices this matters little since the additional cost
is limited to misaligned head and tail blocks.

One thing that may be worth considering is switching bi_size from bytes
to blocks for REQ_FS. That would give us some headroom without
increasing bi_size beyond 32 bits. But I'm not entirely sure it's worth
the pain.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
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/