linux-kernel - Re: [PATCH v3 14/16] Gut bio_add

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: <20120528202839.GA18537@dhcp-172-17-108-109.mtv.corp.google.com>
Date:	Tue, 29 May 2012 05:28:39 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	Alasdair G Kergon <agk@...hat.com>,
	Kent Overstreet <koverstreet@...gle.com>,
	Mike Snitzer <snitzer@...hat.com>,
	linux-kernel@...r.kernel.org, linux-bcache@...r.kernel.org,
	dm-devel@...hat.com, linux-fsdevel@...r.kernel.org,
	axboe@...nel.dk, yehuda@...newdream.net, vgoyal@...hat.com,
	bharrosh@...asas.com, sage@...dream.net, drbd-dev@...ts.linbit.com,
	Dave Chinner <dchinner@...hat.com>, tytso@...gle.com
Subject: Re: [PATCH v3 14/16] Gut bio_add_page()

Hello,

On Mon, May 28, 2012 at 12:07:14PM -0400, Mikulas Patocka wrote:
> With accurately sized bios, you send one bio for 256 sectors (it is sent 
> immediatelly to the disk) and a second bio for another 256 sectors (it is 
> put to the block device queue). The first bio finishes, pages are marked 
> as uptodate, the second bio is sent to the disk. While the disk is 

They're split and made in-flight together.

> processing the second bio, the kernel already knows that the first 256 
> sectors are finished - so it copies the data to userspace and lets the 
> userspace process them - while the disk is processing the second bio. So, 
> disk transfer and data processing are overlapped.
>
> Now, with your patch, you send just one 512-sector bio. The bio is split 
> to two bios, the first one is sent to the disk and you wait. The disk 
> finishes the first bio, you send the second bio to the disk and wait. The 
> disk finishes the second bio. You complete the master bio, mark all 512 
> sectors as uptodate in the pagecache, start copying data to the userspace 
> and processing them. Disk transfer and data processing are not overlapped.

Disk will most likely seek to the sector read all of them into buffer
at once and then serve the two consecutive commands back-to-back
without much inter-command delay.

> accurately-sized bios (that don't span stripe boundaries), each bio waits 
> just for one disk to seek to the requested position. If you send oversized 
> bio that spans several stripes, that bio will wait until all the disks 
> seek to the requested position.
> 
> In general, you can send oversized bios if the user is waiting for all the 
> data requested (for example O_DIRECT read or write). You shouldn't send 
> oversized bios if the user is waiting just for a small part of data and 
> the kernel is doing readahead - in this case, oversized bio will result in 
> additional delay.

Isn't it more like you shouldn't be sending read requested by user and
read ahead in the same bio?

> I think bio_add_page should be simplified in such a way that in the most 
> common cases it doesn't create oversized bio, but it can create oversized 
> bios in uncommon cases. We could retain a limit on a maximum number of 
> sectors (this limit is most commonly hit on disks), put a stripe boundary 
> to queue_limits (the stripe boundary limit is most commonly hit on raid), 
> ignore the rest of the limits in bio_add_page and remove merge_bvec.

If exposing segmenting limit upwards is a must (I'm kinda skeptical),
let's have proper hints (or dynamic hinting interface) instead.

Thanks.

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