Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Kent Overstreet]

On Thu, Nov 03, 2016 at 07:26:52PM +0800, Ming Lei wrote:
> On Thu, Nov 3, 2016 at 7:20 PM, Kent Overstreet
>  wrote:
> > On Thu, Nov 03, 2016 at 06:38:57PM +0800, Ming Lei wrote:
> >> On Wed, Nov 2, 2016 at 11:08 AM, Kent Overstreet
> >>  wrote:
> >> > On Mon, Oct 31, 2016 at 08:39:15AM -0700, Christoph Hellwig wrote:
> >> >> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
> >> >> > Some drivers(such as dm) should be capable of dealing with multipage
> >> >> > bvec, but the incoming bio may be too big, such as, a new singlepage 
> >> >> > bvec
> >> >> > bio can't be cloned from the bio, or can't be allocated to singlepage
> >> >> > bvec with same size.
> >> >> >
> >> >> > At least crypt dm, log writes and bcache have this kind of issue.
> >> >>
> >> >> We already have the segment_size limitation for request based drivers.
> >> >> I'd rather extent it to bio drivers if really needed.
> >> >>
> >> >> But then again we should look into not having this limitation.  E.g.
> >> >> for bcache I'd be really surprised if it's that limited, given that
> >> >> Kent came up with this whole multipage bvec scheme.
> >> >
> >> > AFAIK the only issue is with drivers that may have to bounce bios - 
> >> > pages that
> >> > were contiguous in the original bio won't necessarily be contiguous in 
> >> > the
> >> > bounced bio, thus bouncing might require more than BIO_MAX_SEGMENTS 
> >> > bvecs.
> >> >
> >> > I don't know what Ming's referring to by "singlepage bvec bios".
> >> >
> >> > Anyways, bouncing comes up in multiple places so we probably need to 
> >> > come up
> >> > with a generic solution for that. Other than that, there shouldn't be 
> >> > any issues
> >> > or limitations - if you're not bouncing, there's no need to clone the 
> >> > bvecs.
> >>
> >> AFAIK, the only special case is bch_data_verify(): 
> >> drivers/md/bcache/debug.c,
> >> for other bio_clone(), no direct access to io vec table, so default
> >> multipage bvec
> >> copy is fine.
> >>
> >> I will remove the flag and try to fix bch_data_verify() by using multiple 
> >> bio,
> >> and I remembered I cooked patch to do that long time ago, :-)
> >
> > You can #ifdef out the bch_data_verify() code, it's debug code that hasn't 
> > been
> > used in ages.
> 
> Though you didn't test it ages, it is sitll working in my last test, :-)
> 
> But someone can enable that for debug too, I don't want to make him/her sad.

Up to you :)

It's not useful for anything but debugging though, so I wouldn't worry about
impacting end users.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Ming Lei]

On Thu, Nov 3, 2016 at 7:20 PM, Kent Overstreet
 wrote:
> On Thu, Nov 03, 2016 at 06:38:57PM +0800, Ming Lei wrote:
>> On Wed, Nov 2, 2016 at 11:08 AM, Kent Overstreet
>>  wrote:
>> > On Mon, Oct 31, 2016 at 08:39:15AM -0700, Christoph Hellwig wrote:
>> >> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
>> >> > Some drivers(such as dm) should be capable of dealing with multipage
>> >> > bvec, but the incoming bio may be too big, such as, a new singlepage 
>> >> > bvec
>> >> > bio can't be cloned from the bio, or can't be allocated to singlepage
>> >> > bvec with same size.
>> >> >
>> >> > At least crypt dm, log writes and bcache have this kind of issue.
>> >>
>> >> We already have the segment_size limitation for request based drivers.
>> >> I'd rather extent it to bio drivers if really needed.
>> >>
>> >> But then again we should look into not having this limitation.  E.g.
>> >> for bcache I'd be really surprised if it's that limited, given that
>> >> Kent came up with this whole multipage bvec scheme.
>> >
>> > AFAIK the only issue is with drivers that may have to bounce bios - pages 
>> > that
>> > were contiguous in the original bio won't necessarily be contiguous in the
>> > bounced bio, thus bouncing might require more than BIO_MAX_SEGMENTS bvecs.
>> >
>> > I don't know what Ming's referring to by "singlepage bvec bios".
>> >
>> > Anyways, bouncing comes up in multiple places so we probably need to come 
>> > up
>> > with a generic solution for that. Other than that, there shouldn't be any 
>> > issues
>> > or limitations - if you're not bouncing, there's no need to clone the 
>> > bvecs.
>>
>> AFAIK, the only special case is bch_data_verify(): drivers/md/bcache/debug.c,
>> for other bio_clone(), no direct access to io vec table, so default
>> multipage bvec
>> copy is fine.
>>
>> I will remove the flag and try to fix bch_data_verify() by using multiple 
>> bio,
>> and I remembered I cooked patch to do that long time ago, :-)
>
> You can #ifdef out the bch_data_verify() code, it's debug code that hasn't 
> been
> used in ages.

Though you didn't test it ages, it is sitll working in my last test, :-)

But someone can enable that for debug too, I don't want to make him/her sad.

-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Kent Overstreet]

On Thu, Nov 03, 2016 at 06:38:57PM +0800, Ming Lei wrote:
> On Wed, Nov 2, 2016 at 11:08 AM, Kent Overstreet
>  wrote:
> > On Mon, Oct 31, 2016 at 08:39:15AM -0700, Christoph Hellwig wrote:
> >> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
> >> > Some drivers(such as dm) should be capable of dealing with multipage
> >> > bvec, but the incoming bio may be too big, such as, a new singlepage bvec
> >> > bio can't be cloned from the bio, or can't be allocated to singlepage
> >> > bvec with same size.
> >> >
> >> > At least crypt dm, log writes and bcache have this kind of issue.
> >>
> >> We already have the segment_size limitation for request based drivers.
> >> I'd rather extent it to bio drivers if really needed.
> >>
> >> But then again we should look into not having this limitation.  E.g.
> >> for bcache I'd be really surprised if it's that limited, given that
> >> Kent came up with this whole multipage bvec scheme.
> >
> > AFAIK the only issue is with drivers that may have to bounce bios - pages 
> > that
> > were contiguous in the original bio won't necessarily be contiguous in the
> > bounced bio, thus bouncing might require more than BIO_MAX_SEGMENTS bvecs.
> >
> > I don't know what Ming's referring to by "singlepage bvec bios".
> >
> > Anyways, bouncing comes up in multiple places so we probably need to come up
> > with a generic solution for that. Other than that, there shouldn't be any 
> > issues
> > or limitations - if you're not bouncing, there's no need to clone the bvecs.
> 
> AFAIK, the only special case is bch_data_verify(): drivers/md/bcache/debug.c,
> for other bio_clone(), no direct access to io vec table, so default
> multipage bvec
> copy is fine.
> 
> I will remove the flag and try to fix bch_data_verify() by using multiple bio,
> and I remembered I cooked patch to do that long time ago, :-)

You can #ifdef out the bch_data_verify() code, it's debug code that hasn't been
used in ages.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Ming Lei]

On Wed, Nov 2, 2016 at 11:08 AM, Kent Overstreet
 wrote:
> On Mon, Oct 31, 2016 at 08:39:15AM -0700, Christoph Hellwig wrote:
>> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
>> > Some drivers(such as dm) should be capable of dealing with multipage
>> > bvec, but the incoming bio may be too big, such as, a new singlepage bvec
>> > bio can't be cloned from the bio, or can't be allocated to singlepage
>> > bvec with same size.
>> >
>> > At least crypt dm, log writes and bcache have this kind of issue.
>>
>> We already have the segment_size limitation for request based drivers.
>> I'd rather extent it to bio drivers if really needed.
>>
>> But then again we should look into not having this limitation.  E.g.
>> for bcache I'd be really surprised if it's that limited, given that
>> Kent came up with this whole multipage bvec scheme.
>
> AFAIK the only issue is with drivers that may have to bounce bios - pages that
> were contiguous in the original bio won't necessarily be contiguous in the
> bounced bio, thus bouncing might require more than BIO_MAX_SEGMENTS bvecs.
>
> I don't know what Ming's referring to by "singlepage bvec bios".
>
> Anyways, bouncing comes up in multiple places so we probably need to come up
> with a generic solution for that. Other than that, there shouldn't be any 
> issues
> or limitations - if you're not bouncing, there's no need to clone the bvecs.

AFAIK, the only special case is bch_data_verify(): drivers/md/bcache/debug.c,
for other bio_clone(), no direct access to io vec table, so default
multipage bvec
copy is fine.

I will remove the flag and try to fix bch_data_verify() by using multiple bio,
and I remembered I cooked patch to do that long time ago, :-)


Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Kent Overstreet]

On Mon, Oct 31, 2016 at 08:39:15AM -0700, Christoph Hellwig wrote:
> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
> > Some drivers(such as dm) should be capable of dealing with multipage
> > bvec, but the incoming bio may be too big, such as, a new singlepage bvec
> > bio can't be cloned from the bio, or can't be allocated to singlepage
> > bvec with same size.
> > 
> > At least crypt dm, log writes and bcache have this kind of issue.
> 
> We already have the segment_size limitation for request based drivers.
> I'd rather extent it to bio drivers if really needed.
> 
> But then again we should look into not having this limitation.  E.g.
> for bcache I'd be really surprised if it's that limited, given that
> Kent came up with this whole multipage bvec scheme.

AFAIK the only issue is with drivers that may have to bounce bios - pages that
were contiguous in the original bio won't necessarily be contiguous in the
bounced bio, thus bouncing might require more than BIO_MAX_SEGMENTS bvecs.

I don't know what Ming's referring to by "singlepage bvec bios".

Anyways, bouncing comes up in multiple places so we probably need to come up
with a generic solution for that. Other than that, there shouldn't be any issues
or limitations - if you're not bouncing, there's no need to clone the bvecs.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Ming Lei]

On Mon, Oct 31, 2016 at 11:39 PM, Christoph Hellwig  wrote:
> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
>> Some drivers(such as dm) should be capable of dealing with multipage
>> bvec, but the incoming bio may be too big, such as, a new singlepage bvec
>> bio can't be cloned from the bio, or can't be allocated to singlepage
>> bvec with same size.
>>
>> At least crypt dm, log writes and bcache have this kind of issue.
>
> We already have the segment_size limitation for request based drivers.
> I'd rather extent it to bio drivers if really needed.

Yeah, just found dm actually don't need the flag, and it has its own way
for limitting bio size. For bcache, there is only place which need the
flag, so we can use max sectors limit to address it or use multiple bio
to read & check ony by one.

>
> But then again we should look into not having this limitation.  E.g.
> for bcache I'd be really surprised if it's that limited, given that
> Kent came up with this whole multipage bvec scheme.

As far as I find, the only one which need the flag is bch_data_verify().


Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Christoph Hellwig]

On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
> Some drivers(such as dm) should be capable of dealing with multipage
> bvec, but the incoming bio may be too big, such as, a new singlepage bvec
> bio can't be cloned from the bio, or can't be allocated to singlepage
> bvec with same size.
> 
> At least crypt dm, log writes and bcache have this kind of issue.

We already have the segment_size limitation for request based drivers.
I'd rather extent it to bio drivers if really needed.

But then again we should look into not having this limitation.  E.g.
for bcache I'd be really surprised if it's that limited, given that
Kent came up with this whole multipage bvec scheme.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html