Re: [PATCH] block: loose check on sg gap

On Wed, Jan 11, 2017 at 1:10 PM, Dexuan Cui [off-list ref] wrote:

quoted

From: Dexuan Cui
Sent: Tuesday, December 20, 2016 11:41
To: 'Jens Axboe' <axboe@fb.com>; Ming Lei <redacted>
Cc: Linux Kernel Mailing List <redacted>; linux-block
[off-list ref]; Christoph Hellwig [off-list ref];
Vitaly Kuznetsov [off-list ref]; Keith Busch
[off-list ref]; Hannes Reinecke [off-list ref]; Mike Christie
[off-list ref]; Martin K. Petersen [off-list ref];
Toshi Kani [off-list ref]; Dan Williams [off-list ref];
Damien Le Moal [off-list ref]
Subject: RE: [PATCH] block: loose check on sg gap

quoted

From: Jens Axboe [mailto:axboe@fb.com]
Sent: Tuesday, December 20, 2016 10:31
To: Ming Lei <redacted>
Cc: Linux Kernel Mailing List <redacted>; linux-block

<linux-

quoted

block@vger.kernel.org>; Christoph Hellwig [off-list ref]; Dexuan

Cui

quoted

[off-list ref]; Vitaly Kuznetsov [off-list ref]; Keith

Busch

quoted

[off-list ref]; Hannes Reinecke [off-list ref]; Mike Christie
[off-list ref]; Martin K. Petersen

[off-list ref];

quoted

Toshi Kani [off-list ref]; Dan Williams

[off-list ref];

quoted

Damien Le Moal [off-list ref]
Subject: Re: [PATCH] block: loose check on sg gap

On 12/19/2016 07:07 PM, Ming Lei wrote:

quoted

On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe [off-list ref] wrote:

quoted

On 12/17/2016 03:49 AM, Ming Lei wrote:

quoted

If the last bvec of the 1st bio and the 1st bvec of the next
bio are contineous physically, and the latter can be merged
to last segment of the 1st bio, we should think they don't
violate sg gap(or virt boundary) limit.

Both Vitaly and Dexuan reported lots of unmergeable small bios
are observed when running mkfs on Hyper-V virtual storage, and
performance becomes quite low, so this patch is figured out for
fixing the performance issue.

The same issue should exist on NVMe too sine it sets virt boundary

too.

quoted

quoted

quoted

It looks pretty reasonable to me. I'll queue it up for some testing,
changes like this always make me a little nervous.

Understood.

But given it is still in early stage of 4.10 cycle, seems fine to expose
it now, and we should have enough time to fix it if there might be
regressions.

BTW, it passes my xfstest(ext4) over sata/NVMe.

It's been fine here in testing, too. I'm not worried about performance
regressions, those we can always fix. Merging makes me worried about
corruption, and those regressions are much worse.

Any reason we need to rush this? I'd be more comfortable pushing this to
4.11, unless there are strong reasons this should make 4.10.

--
Jens Axboe

Hi Jens,

As far as I know, the patch is important to popular Linux distros,
e.g. at least Ubuntu 14.04.5, 16.x and RHEL 7.3, when they run on
Hyper-V/Azure, because they can suffer from a pretty bad
throughput/latency
in some cases, e.g. mkfs.ext4 for a 100GB partition can take 8 minutes, but
with the patch, it only takes 1 second.

-- Dexuan

Hi Ming, Jens,
Did you find any issue later when testing with the patch?

May I know if it's possible to have it in 4.10 considering the above impact?

Is it on some temporary branch of linux-block.git? Looks not.

Dexuan, Jens has said that this patch may land v4.11, so just wait a release
and let it expose into more tests.

Thanks,
Ming