- Subject: Re: [PATCH v5 08/12] block: Introduce new bio_split()
- From: Kent Overstreet <koverstreet@xxxxxxxxxx>
- Date: Wed, 8 Aug 2012 18:39:23 -0700
- Cc: axboe@xxxxxxxxx, dm-devel@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-bcache@xxxxxxxxxxxxxxx, mpatocka@xxxxxxxxxx, vgoyal@xxxxxxxxxx, yehuda@xxxxxxxxxxxxxxx, sage@xxxxxxxxxxxx, agk@xxxxxxxxxx, drbd-dev@xxxxxxxxxxxxxxxx
- In-reply-to: <20120808230532.GH6983@dhcp-172-17-108-109.mtv.corp.google.com>
- References: <1344290921-25154-1-git-send-email-koverstreet@google.com> <1344290921-25154-9-git-send-email-koverstreet@google.com> <20120808230532.GH6983@dhcp-172-17-108-109.mtv.corp.google.com>
- Reply-to: device-mapper development <dm-devel@xxxxxxxxxx>
- User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Aug 08, 2012 at 04:05:32PM -0700, Tejun Heo wrote:
> One more thing.
>
> On Mon, Aug 06, 2012 at 03:08:37PM -0700, Kent Overstreet wrote:
> > + if (bio_integrity(bio)) {
> > + bio_integrity_clone(ret, bio, gfp, bs);
> > + bio_integrity_trim(ret, 0, bio_sectors(ret));
> > + bio_integrity_trim(bio, bio_sectors(ret), bio_sectors(bio));
>
> Is this equivalent to bio_integrity_split() performance-wise?
Strictly speaking, no. But it has the advantage of being drastically
simpler - and the only one only worked for single page bios so I
would've had to come up with something new from scratch, and as
confusing as the integrity stuff is I wouldn't trust the result.
I'm skeptical that it's going to matter in practice given how much
iteration is done elsewhere in the course of processing a bio and given
that this stuff isn't used with high end SSDs...
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
[DM Crypt]
[Fedora Desktop]
[ATA RAID]
[Fedora Marketing]
[Fedora Packaging]
[Fedora SELinux]
[Yosemite Discussion]
[Yosemite Photos]
[KDE Users]
[Fedora Tools]
[Fedora Docs]