Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, 2015-08-10 at 11:02 -0400, Mike Snitzer wrote: > On Sun, Aug 09 2015 at 3:18am -0400, > Ming Lin <mlin at kernel.org> wrote: > > > On Sun, 2015-08-09 at 00:01 -0700, Christoph Hellwig wrote: > > > On Sat, Aug 08, 2015 at 11:55:47PM -0700, Ming Lin wrote: > > > > Will change it to MAX_BIO_SECTORS. > > > > May I add your ACK? > > > > > > Yes, please go ahead. > > > > Thanks. I'll send a new version of the series once device-mapper guy > > acks. > > > > Hi Mike, > > > > I have updated my tree. Could you pull and re-test? > > https://git.kernel.org/cgit/linux/kernel/git/mlin/linux.git/log/?h=block-generic-req > > > > The 2 thin-provisioning tests passed. > > I've merged your latest branch with my dm-4.3 branch, I had one conflict > in the merge due to the dm_merge_bvec() change from 4.2-rc6 (no > surprise). I've published the result here: > http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=block-late-bio-splitting > > It passes the device-mapper-test-suite's 'thin-provisioning' tests. > > > Hope I can have your ACK soon. > > Shouldn't we also be using MAX_BIO_SECTORS in blkdev_issue_write_same > (instead of UINT_MAX >> 9)? I also prefer using MAX_BIO_SECTORS. Otherwise, we may have non page size aligned splits. Say, write_same 8G. Using UINT_MAX >> 9, we'll have 2 sector aligned splits in blkdev_issue_write_same(): 0 - (4G - 512 - 1) (4G - 512, 8G -1) This looks weired. Using MAX_BIO_SECTORS, we'll have 4 page size aligned splits: 0 - (2G -1) 2G - (4G - 1) 4G - (6G - 1) 6G - (8G - 1) I'll use MAX_BIO_SECTORS in blkdev_issue_write_same() if no objection. > > Aside from that, I'm in favor of seeing this late bio splitting patchset > finally land upstream (hopefully in time for the 4.3 merge, Jens?): > > Acked-by: Mike Snitzer <snitzer at redhat.com> Thanks! May I add your Ack to "PATCH: block: kill merge_bvec_fn() completely" also? > > p.s. I'll be working with Joe Thornber on optimizing DM (particularly > dm-thinp and dm-cache) once this patchset is included upstream. You'll > see I've already added a couple WIP dm-thinp patches ontop.