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

2017-01-11 Thread Dexuan Cui 
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Thursday, January 12, 2017 10:54
> To: Dexuan Cui <de...@microsoft.com>
> Cc: Jens Axboe <ax...@fb.com>; Linux Kernel Mailing List  ker...@vger.kernel.org>; linux-block <linux-bl...@vger.kernel.org>;
> Christoph Hellwig <h...@infradead.org>; Vitaly Kuznetsov
> <vkuzn...@redhat.com>; Keith Busch <keith.bu...@intel.com>; Hannes
> Reinecke <h...@suse.de>; Mike Christie <mchri...@redhat.com>; Martin K.
> Petersen <martin.peter...@oracle.com>; Toshi Kani <toshi.k...@hpe.com>;
> Dan Williams <dan.j.willi...@intel.com>; Damien Le Moal
> <damien.lem...@hgst.com>; KY Srinivasan <k...@microsoft.com>
> Subject: Re: [PATCH] block: loose check on sg gap
> 
> On Wed, Jan 11, 2017 at 1:10 PM, Dexuan Cui <de...@microsoft.com> wrote:
> >> From: Dexuan Cui
> >> Sent: Tuesday, December 20, 2016 11:41
> >> To: 'Jens Axboe' <ax...@fb.com>; Ming Lei <ming@canonical.com>
> >> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block
> >> <linux-bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>;
> >> Vitaly Kuznetsov <vkuzn...@redhat.com>; Keith Busch
> >> <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike
> Christie
> >> <mchri...@redhat.com>; Martin K. Petersen
> <martin.peter...@oracle.com>;
> >> Toshi Kani <toshi.k...@hpe.com>; Dan Williams
> <dan.j.willi...@intel.com>;
> >> Damien Le Moal <damien.lem...@hgst.com>
> >> Subject: RE: [PATCH] block: loose check on sg gap
> >>
> >> > From: Jens Axboe [mailto:ax...@fb.com]
> >> > Sent: Tuesday, December 20, 2016 10:31
> >> > To: Ming Lei <ming@canonical.com>
> >> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block
> >>  >> > bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>;
> Dexuan
> >> Cui
> >> > <de...@microsoft.com>; Vitaly Kuznetsov <vkuzn...@redhat.com>;
> Keith
> >> Busch
> >> > <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike
> Christie
> >> > <mchri...@redhat.com>; Martin K. Petersen
> >> <martin.peter...@oracle.com>;
> >> > Toshi Kani <toshi.k...@hpe.com>; Dan Williams
> >> <dan.j.willi...@intel.com>;
> >> > Damien Le Moal <damien.lem...@hgst.com>
> >> > Subject: Re: [PATCH] block: loose check on sg gap
> >> >
> >> > On 12/19/2016 07:07 PM, Ming Lei wrote:
> >> > > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe <ax...@fb.com> wrote:
> >> > >> On 12/17/2016 03:49 AM, Ming Lei wrote:
> >> > >>> 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.
> >> > >>
> >> > >> 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

Thanks for the reply!

Sorry, I didn't mean to be pushy -- I just wanted to get more idea about the
status of the patch, since I'm unfamiliar with the linux-block repo. :-)

BTW, I've been using the patch for ~1 month and I didn't get any issue.

Thanks,
-- Dexuan

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

2017-01-11 Thread Dexuan Cui 
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Thursday, January 12, 2017 10:54
> To: Dexuan Cui 
> Cc: Jens Axboe ; Linux Kernel Mailing List  ker...@vger.kernel.org>; linux-block ;
> Christoph Hellwig ; Vitaly Kuznetsov
> ; Keith Busch ; Hannes
> Reinecke ; Mike Christie ; Martin K.
> Petersen ; Toshi Kani ;
> Dan Williams ; Damien Le Moal
> ; KY Srinivasan 
> Subject: Re: [PATCH] block: loose check on sg gap
> 
> On Wed, Jan 11, 2017 at 1:10 PM, Dexuan Cui  wrote:
> >> From: Dexuan Cui
> >> Sent: Tuesday, December 20, 2016 11:41
> >> To: 'Jens Axboe' ; Ming Lei 
> >> Cc: Linux Kernel Mailing List ; linux-block
> >> ; Christoph Hellwig ;
> >> Vitaly Kuznetsov ; Keith Busch
> >> ; Hannes Reinecke ; Mike
> Christie
> >> ; Martin K. Petersen
> ;
> >> Toshi Kani ; Dan Williams
> ;
> >> Damien Le Moal 
> >> Subject: RE: [PATCH] block: loose check on sg gap
> >>
> >> > From: Jens Axboe [mailto:ax...@fb.com]
> >> > Sent: Tuesday, December 20, 2016 10:31
> >> > To: Ming Lei 
> >> > Cc: Linux Kernel Mailing List ; linux-block
> >>  >> > bl...@vger.kernel.org>; Christoph Hellwig ;
> Dexuan
> >> Cui
> >> > ; Vitaly Kuznetsov ;
> Keith
> >> Busch
> >> > ; Hannes Reinecke ; Mike
> Christie
> >> > ; Martin K. Petersen
> >> ;
> >> > Toshi Kani ; Dan Williams
> >> ;
> >> > Damien Le Moal 
> >> > Subject: Re: [PATCH] block: loose check on sg gap
> >> >
> >> > On 12/19/2016 07:07 PM, Ming Lei wrote:
> >> > > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
> >> > >> On 12/17/2016 03:49 AM, Ming Lei wrote:
> >> > >>> 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.
> >> > >>
> >> > >> 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

Thanks for the reply!

Sorry, I didn't mean to be pushy -- I just wanted to get more idea about the
status of the patch, since I'm unfamiliar with the linux-block repo. :-)

BTW, I've been using the patch for ~1 month and I didn't get any issue.

Thanks,
-- Dexuan

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

2017-01-11 Thread Ming Lei 
On Wed, Jan 11, 2017 at 1:10 PM, Dexuan Cui <de...@microsoft.com> wrote:
>> From: Dexuan Cui
>> Sent: Tuesday, December 20, 2016 11:41
>> To: 'Jens Axboe' <ax...@fb.com>; Ming Lei <ming@canonical.com>
>> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block
>> <linux-bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>;
>> Vitaly Kuznetsov <vkuzn...@redhat.com>; Keith Busch
>> <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike Christie
>> <mchri...@redhat.com>; Martin K. Petersen <martin.peter...@oracle.com>;
>> Toshi Kani <toshi.k...@hpe.com>; Dan Williams <dan.j.willi...@intel.com>;
>> Damien Le Moal <damien.lem...@hgst.com>
>> Subject: RE: [PATCH] block: loose check on sg gap
>>
>> > From: Jens Axboe [mailto:ax...@fb.com]
>> > Sent: Tuesday, December 20, 2016 10:31
>> > To: Ming Lei <ming@canonical.com>
>> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block
>> > > bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>; Dexuan
>> Cui
>> > <de...@microsoft.com>; Vitaly Kuznetsov <vkuzn...@redhat.com>; Keith
>> Busch
>> > <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike Christie
>> > <mchri...@redhat.com>; Martin K. Petersen
>> <martin.peter...@oracle.com>;
>> > Toshi Kani <toshi.k...@hpe.com>; Dan Williams
>> <dan.j.willi...@intel.com>;
>> > Damien Le Moal <damien.lem...@hgst.com>
>> > Subject: Re: [PATCH] block: loose check on sg gap
>> >
>> > On 12/19/2016 07:07 PM, Ming Lei wrote:
>> > > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe <ax...@fb.com> wrote:
>> > >> On 12/17/2016 03:49 AM, Ming Lei wrote:
>> > >>> 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.
>> > >>
>> > >> 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

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

2017-01-11 Thread Ming Lei 
On Wed, Jan 11, 2017 at 1:10 PM, Dexuan Cui  wrote:
>> From: Dexuan Cui
>> Sent: Tuesday, December 20, 2016 11:41
>> To: 'Jens Axboe' ; Ming Lei 
>> Cc: Linux Kernel Mailing List ; linux-block
>> ; Christoph Hellwig ;
>> Vitaly Kuznetsov ; Keith Busch
>> ; Hannes Reinecke ; Mike Christie
>> ; Martin K. Petersen ;
>> Toshi Kani ; Dan Williams ;
>> Damien Le Moal 
>> Subject: RE: [PATCH] block: loose check on sg gap
>>
>> > From: Jens Axboe [mailto:ax...@fb.com]
>> > Sent: Tuesday, December 20, 2016 10:31
>> > To: Ming Lei 
>> > Cc: Linux Kernel Mailing List ; linux-block
>> > > bl...@vger.kernel.org>; Christoph Hellwig ; Dexuan
>> Cui
>> > ; Vitaly Kuznetsov ; Keith
>> Busch
>> > ; Hannes Reinecke ; Mike Christie
>> > ; Martin K. Petersen
>> ;
>> > Toshi Kani ; Dan Williams
>> ;
>> > Damien Le Moal 
>> > Subject: Re: [PATCH] block: loose check on sg gap
>> >
>> > On 12/19/2016 07:07 PM, Ming Lei wrote:
>> > > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
>> > >> On 12/17/2016 03:49 AM, Ming Lei wrote:
>> > >>> 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.
>> > >>
>> > >> 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

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

2017-01-10 Thread Dexuan Cui 
> From: Dexuan Cui
> Sent: Tuesday, December 20, 2016 11:41
> To: 'Jens Axboe' <ax...@fb.com>; Ming Lei <ming@canonical.com>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block
> <linux-bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>;
> Vitaly Kuznetsov <vkuzn...@redhat.com>; Keith Busch
> <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike Christie
> <mchri...@redhat.com>; Martin K. Petersen <martin.peter...@oracle.com>;
> Toshi Kani <toshi.k...@hpe.com>; Dan Williams <dan.j.willi...@intel.com>;
> Damien Le Moal <damien.lem...@hgst.com>
> Subject: RE: [PATCH] block: loose check on sg gap
> 
> > From: Jens Axboe [mailto:ax...@fb.com]
> > Sent: Tuesday, December 20, 2016 10:31
> > To: Ming Lei <ming@canonical.com>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block
>  > bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>; Dexuan
> Cui
> > <de...@microsoft.com>; Vitaly Kuznetsov <vkuzn...@redhat.com>; Keith
> Busch
> > <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike Christie
> > <mchri...@redhat.com>; Martin K. Petersen
> <martin.peter...@oracle.com>;
> > Toshi Kani <toshi.k...@hpe.com>; Dan Williams
> <dan.j.willi...@intel.com>;
> > Damien Le Moal <damien.lem...@hgst.com>
> > Subject: Re: [PATCH] block: loose check on sg gap
> >
> > On 12/19/2016 07:07 PM, Ming Lei wrote:
> > > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe <ax...@fb.com> wrote:
> > >> On 12/17/2016 03:49 AM, Ming Lei wrote:
> > >>> 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.
> > >>
> > >> 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.

Thanks,
-- Dexuan

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

2017-01-10 Thread Dexuan Cui 
> From: Dexuan Cui
> Sent: Tuesday, December 20, 2016 11:41
> To: 'Jens Axboe' ; Ming Lei 
> Cc: Linux Kernel Mailing List ; linux-block
> ; Christoph Hellwig ;
> Vitaly Kuznetsov ; Keith Busch
> ; Hannes Reinecke ; Mike Christie
> ; Martin K. Petersen ;
> Toshi Kani ; Dan Williams ;
> Damien Le Moal 
> Subject: RE: [PATCH] block: loose check on sg gap
> 
> > From: Jens Axboe [mailto:ax...@fb.com]
> > Sent: Tuesday, December 20, 2016 10:31
> > To: Ming Lei 
> > Cc: Linux Kernel Mailing List ; linux-block
>  > bl...@vger.kernel.org>; Christoph Hellwig ; Dexuan
> Cui
> > ; Vitaly Kuznetsov ; Keith
> Busch
> > ; Hannes Reinecke ; Mike Christie
> > ; Martin K. Petersen
> ;
> > Toshi Kani ; Dan Williams
> ;
> > Damien Le Moal 
> > Subject: Re: [PATCH] block: loose check on sg gap
> >
> > On 12/19/2016 07:07 PM, Ming Lei wrote:
> > > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
> > >> On 12/17/2016 03:49 AM, Ming Lei wrote:
> > >>> 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.
> > >>
> > >> 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.

Thanks,
-- Dexuan

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

2016-12-19 Thread Dexuan Cui 
> From: Jens Axboe [mailto:ax...@fb.com]
> Sent: Tuesday, December 20, 2016 10:31
> To: Ming Lei <ming@canonical.com>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; linux-block 
>  bl...@vger.kernel.org>; Christoph Hellwig <h...@infradead.org>; Dexuan Cui
> <de...@microsoft.com>; Vitaly Kuznetsov <vkuzn...@redhat.com>; Keith Busch
> <keith.bu...@intel.com>; Hannes Reinecke <h...@suse.de>; Mike Christie
> <mchri...@redhat.com>; Martin K. Petersen <martin.peter...@oracle.com>;
> Toshi Kani <toshi.k...@hpe.com>; Dan Williams <dan.j.willi...@intel.com>;
> Damien Le Moal <damien.lem...@hgst.com>
> Subject: Re: [PATCH] block: loose check on sg gap
> 
> On 12/19/2016 07:07 PM, Ming Lei wrote:
> > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe <ax...@fb.com> wrote:
> >> On 12/17/2016 03:49 AM, Ming Lei wrote:
> >>> 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.
> >>
> >> 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.

Thanks,
-- Dexuan

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

2016-12-19 Thread Dexuan Cui 
> From: Jens Axboe [mailto:ax...@fb.com]
> Sent: Tuesday, December 20, 2016 10:31
> To: Ming Lei 
> Cc: Linux Kernel Mailing List ; linux-block 
>  bl...@vger.kernel.org>; Christoph Hellwig ; Dexuan Cui
> ; Vitaly Kuznetsov ; Keith Busch
> ; Hannes Reinecke ; Mike Christie
> ; Martin K. Petersen ;
> Toshi Kani ; Dan Williams ;
> Damien Le Moal 
> Subject: Re: [PATCH] block: loose check on sg gap
> 
> On 12/19/2016 07:07 PM, Ming Lei wrote:
> > On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
> >> On 12/17/2016 03:49 AM, Ming Lei wrote:
> >>> 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.
> >>
> >> 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.

Thanks,
-- Dexuan

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

2016-12-19 Thread Jens Axboe 
On 12/19/2016 07:07 PM, Ming Lei wrote:
> On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
>> On 12/17/2016 03:49 AM, Ming Lei wrote:
>>> 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.
>>
>> 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

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

2016-12-19 Thread Jens Axboe 
On 12/19/2016 07:07 PM, Ming Lei wrote:
> On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
>> On 12/17/2016 03:49 AM, Ming Lei wrote:
>>> 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.
>>
>> 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

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

2016-12-19 Thread Ming Lei 
On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
> On 12/17/2016 03:49 AM, Ming Lei wrote:
>> 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.
>
> 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.

Thanks,
Ming

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

2016-12-19 Thread Ming Lei 
On Sun, Dec 18, 2016 at 12:49 AM, Jens Axboe  wrote:
> On 12/17/2016 03:49 AM, Ming Lei wrote:
>> 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.
>
> 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.

Thanks,
Ming

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

2016-12-17 Thread Jens Axboe 
On 12/17/2016 03:49 AM, Ming Lei wrote:
> 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.

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

-- 
Jens Axboe

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

2016-12-17 Thread Jens Axboe 
On 12/17/2016 03:49 AM, Ming Lei wrote:
> 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.

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

-- 
Jens Axboe

[PATCH] block: loose check on sg gap

2016-12-17 Thread Ming Lei 
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.

Reported-by: Vitaly Kuznetsov 
Reported-by: Dexuan Cui 
Tested-by: Dexuan Cui 
Cc: Keith Busch 
Signed-off-by: Ming Lei 
---
 include/linux/blkdev.h | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 286b2a264383..1ce26e771bcc 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1608,6 +1608,25 @@ static inline bool bvec_gap_to_prev(struct request_queue 
*q,
return __bvec_gap_to_prev(q, bprv, offset);
 }
 
+/*
+ * Check if the two bvecs from two bios can be merged to one segment.
+ * If yes, no need to check gap between the two bios since the 1st bio
+ * and the 1st bvec in the 2nd bio can be handled in one segment.
+ */
+static inline bool bios_segs_mergeable(struct request_queue *q,
+   struct bio *prev, struct bio_vec *prev_last_bv,
+   struct bio_vec *next_first_bv)
+{
+   if (!BIOVEC_PHYS_MERGEABLE(prev_last_bv, next_first_bv))
+   return false;
+   if (!BIOVEC_SEG_BOUNDARY(q, prev_last_bv, next_first_bv))
+   return false;
+   if (prev->bi_seg_back_size + next_first_bv->bv_len >
+   queue_max_segment_size(q))
+   return false;
+   return true;
+}
+
 static inline bool bio_will_gap(struct request_queue *q, struct bio *prev,
 struct bio *next)
 {
@@ -1617,7 +1636,8 @@ static inline bool bio_will_gap(struct request_queue *q, 
struct bio *prev,
bio_get_last_bvec(prev, );
bio_get_first_bvec(next, );
 
-   return __bvec_gap_to_prev(q, , nb.bv_offset);
+   if (!bios_segs_mergeable(q, prev, , ))
+   return __bvec_gap_to_prev(q, , nb.bv_offset);
}
 
return false;
-- 
2.7.4

[PATCH] block: loose check on sg gap

2016-12-17 Thread Ming Lei 
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.

Reported-by: Vitaly Kuznetsov 
Reported-by: Dexuan Cui 
Tested-by: Dexuan Cui 
Cc: Keith Busch 
Signed-off-by: Ming Lei 
---
 include/linux/blkdev.h | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 286b2a264383..1ce26e771bcc 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1608,6 +1608,25 @@ static inline bool bvec_gap_to_prev(struct request_queue 
*q,
return __bvec_gap_to_prev(q, bprv, offset);
 }
 
+/*
+ * Check if the two bvecs from two bios can be merged to one segment.
+ * If yes, no need to check gap between the two bios since the 1st bio
+ * and the 1st bvec in the 2nd bio can be handled in one segment.
+ */
+static inline bool bios_segs_mergeable(struct request_queue *q,
+   struct bio *prev, struct bio_vec *prev_last_bv,
+   struct bio_vec *next_first_bv)
+{
+   if (!BIOVEC_PHYS_MERGEABLE(prev_last_bv, next_first_bv))
+   return false;
+   if (!BIOVEC_SEG_BOUNDARY(q, prev_last_bv, next_first_bv))
+   return false;
+   if (prev->bi_seg_back_size + next_first_bv->bv_len >
+   queue_max_segment_size(q))
+   return false;
+   return true;
+}
+
 static inline bool bio_will_gap(struct request_queue *q, struct bio *prev,
 struct bio *next)
 {
@@ -1617,7 +1636,8 @@ static inline bool bio_will_gap(struct request_queue *q, 
struct bio *prev,
bio_get_last_bvec(prev, );
bio_get_first_bvec(next, );
 
-   return __bvec_gap_to_prev(q, , nb.bv_offset);
+   if (!bios_segs_mergeable(q, prev, , ))
+   return __bvec_gap_to_prev(q, , nb.bv_offset);
}
 
return false;
-- 
2.7.4