On Sat, Jan 07, 2017 at 10:01:07AM +1100, NeilBrown wrote:
> On Sat, Jan 07 2017, Mike Snitzer wrote:
> > On Fri, Jan 06 2017 at 12:34pm -0500,
> > Mikulas Patocka wrote:
> >> On Fri, 6 Jan 2017, Mikulas Patocka wrote:
> >> > On Wed, 4 Jan 2017, Mike Snitzer wrote:
> >> > > On Wed, Jan 04 2017 at
On Sat, Jan 07 2017, Mike Snitzer wrote:
> On Fri, Jan 06 2017 at 12:34pm -0500,
> Mikulas Patocka wrote:
>
>>
>>
>> On Fri, 6 Jan 2017, Mikulas Patocka wrote:
>>
>> >
>> >
>> > On Wed, 4 Jan 2017, Mike Snitzer wrote:
>> >
>> > > On Wed, Jan 04 2017 at 12:12am -0500,
>> > > NeilBrown wrote
On Fri, Jan 06 2017 at 12:34pm -0500,
Mikulas Patocka wrote:
>
>
> On Fri, 6 Jan 2017, Mikulas Patocka wrote:
>
> >
> >
> > On Wed, 4 Jan 2017, Mike Snitzer wrote:
> >
> > > On Wed, Jan 04 2017 at 12:12am -0500,
> > > NeilBrown wrote:
> > >
> > > > > Suggested-by: NeilBrown
> > > > > Sig
On Fri, 6 Jan 2017, Mikulas Patocka wrote:
>
>
> On Wed, 4 Jan 2017, Mike Snitzer wrote:
>
> > On Wed, Jan 04 2017 at 12:12am -0500,
> > NeilBrown wrote:
> >
> > > > Suggested-by: NeilBrown
> > > > Signed-off-by: Jack Wang
> > > > ---
> > > > block/blk-core.c | 20
>
On Wed, 4 Jan 2017, Mike Snitzer wrote:
> On Wed, Jan 04 2017 at 12:12am -0500,
> NeilBrown wrote:
>
> > On Tue, Jan 03 2017, Jack Wang wrote:
> >
> > > 2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
> > >> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
> > >>> Dear Maintainers
>
2017-01-04 19:50 GMT+01:00 Mike Snitzer :
> On Wed, Jan 04 2017 at 12:12am -0500,
> NeilBrown wrote:
>
>> On Tue, Jan 03 2017, Jack Wang wrote:
>>
>> > 2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
>> >> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
>> >>> Dear Maintainers
>> >>>
>>
On Wed, Jan 04 2017 at 12:12am -0500,
NeilBrown wrote:
> On Tue, Jan 03 2017, Jack Wang wrote:
>
> > 2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
> >> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
> >>> Dear Maintainers
> >>>
> >>> I'd like to ask for the status of this patch sinc
On Tue, Jan 03 2017, Jack Wang wrote:
> 2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
>> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
>>> Dear Maintainers
>>>
>>> I'd like to ask for the status of this patch since we hit the
>>> issue too during our testing on md raid1.
>>>
>>> Spli
2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
>> Dear Maintainers
>>
>> I'd like to ask for the status of this patch since we hit the
>> issue too during our testing on md raid1.
>>
>> Split remainder bio_A was queued ahead, following by
On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
> Dear Maintainers
>
> I'd like to ask for the status of this patch since we hit the
> issue too during our testing on md raid1.
>
> Split remainder bio_A was queued ahead, following by bio_B for
> lower device, at this moment raid sta
Dear Maintainers
I'd like to ask for the status of this patch since we hit the
issue too during our testing on md raid1.
Split remainder bio_A was queued ahead, following by bio_B for
lower device, at this moment raid start freezing, the loop take
out bio_A firstly and deliver it, which will hung
On Tue, 19 Jul 2016, Lars Ellenberg wrote:
> On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote:
> > On Tue, Jul 12 2016 at 10:18pm -0400,
> > Eric Wheeler wrote:
> >
> > > On Tue, 12 Jul 2016, NeilBrown wrote:
> > >
> > > > On Tue, Jul 12 2016, Lars Ellenberg wrote:
> > > >
> > >
Eric Wheeler writes:
> [+cc Mikulas Patocka, Jeff Moyer; Do either of you have any input on Lars'
> commentary related to patchwork #'s 9204125 and 7398411 and BZ#119841? ]
Sorry, I don't have any time to look at this right now.
Cheers,
Jeff
>
> On Tue, 19 Jul 2016, Lars Ellenberg wrote:
>
>>
[+cc Mikulas Patocka, Jeff Moyer; Do either of you have any input on Lars'
commentary related to patchwork #'s 9204125 and 7398411 and BZ#119841? ]
On Tue, 19 Jul 2016, Lars Ellenberg wrote:
> On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote:
> > On Tue, Jul 12 2016 at 10:18pm -0400,
On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote:
> On Tue, Jul 12 2016 at 10:18pm -0400,
> Eric Wheeler wrote:
>
> > On Tue, 12 Jul 2016, NeilBrown wrote:
> >
> > > On Tue, Jul 12 2016, Lars Ellenberg wrote:
> > >
> > > >
> > > > Instead, I suggest to distinguish between recurs
On Tue, Jul 12 2016 at 10:18pm -0400,
Eric Wheeler wrote:
> On Tue, 12 Jul 2016, NeilBrown wrote:
>
> > On Tue, Jul 12 2016, Lars Ellenberg wrote:
> >
> > >
> > > Instead, I suggest to distinguish between recursive calls to
> > > generic_make_request(), and pushing back the remainder part i
On Tue, 12 Jul 2016, NeilBrown wrote:
> On Tue, Jul 12 2016, Lars Ellenberg wrote:
>
> >
> > Instead, I suggest to distinguish between recursive calls to
> > generic_make_request(), and pushing back the remainder part in
> > blk_queue_split(), by pointing current->bio_lists to a
> > struc
On Tue, Jul 12 2016, Lars Ellenberg wrote:
>
> Instead, I suggest to distinguish between recursive calls to
> generic_make_request(), and pushing back the remainder part in
> blk_queue_split(), by pointing current->bio_lists to a
> struct recursion_to_iteration_bio_lists {
>
Dropped the XXX comment (oops),
moved the current_has_pending_bios() helper to bio.h
and dropped the identical ones from bio.c and md.h.
Reposted in-thread as
[PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion
Thanks,
Lars Ellenberg
For a long time, generic_make_request() converts recursion into
iteration by queuing recursive arguments on current->bio_list.
This is convenient for stacking drivers,
the top-most driver would take the originally submitted bio,
and re-submit a re-mapped version of it, or one or more clones,
or on
On Fri, Jul 08 2016 at 11:04am -0400,
Lars Ellenberg wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for stacking drivers,
> the top-most driver would take the originally submitted bi
For a long time, generic_make_request() converts recursion into
iteration by queuing recursive arguments on current->bio_list.
This is convenient for stacking drivers,
the top-most driver would take the originally submitted bio,
and re-submit a re-mapped version of it, or one or more clones,
or on
Result of RFC previously discussed here:
https://lkml.org/lkml/2016/6/22/172
[RFC] block: fix blk_queue_split() resource exhaustion
Rebased to linux-block/for-4.8/core as of today.
Would also need to go to Stable 4.3 and later.
Lars Ellenberg (1):
block: fix blk_queue_split() resource
On Fri, Jul 08, 2016 at 07:24:24PM +0600, Pavel Goran wrote:
> Friday, July 8, 2016, 7:00:35 PM, you wrote:
> > On Fri, Jul 08, 2016 at 07:39:36PM +1000, NeilBrown wrote:
> >> I think we just might be in violent agreement.
>
> > I thought so, too :-)
>
> > Should I merge both patches,
> > rename
On Fri, Jul 08 2016 at 8:52am -0400,
Lars Ellenberg wrote:
> On Fri, Jul 08, 2016 at 07:08:32PM +0800, Ming Lei wrote:
> > > So after processing a particular bio, we should then process all the
> > > 'child' bios - bios send to underlying devices. Then the 'sibling'
> > > bios, that were split
On Fri, Jul 08, 2016 at 07:39:36PM +1000, NeilBrown wrote:
> >> To make the patch "perfect", and maybe even more elegant we could treat
> >> ->remainder and ->recursion more alike.
> >> i.e.:
> >> - generic make request has a private "stack" of requests.
> >> - before calling ->make_request_fn(
On Fri, Jul 08, 2016 at 07:08:32PM +0800, Ming Lei wrote:
> > So after processing a particular bio, we should then process all the
> > 'child' bios - bios send to underlying devices. Then the 'sibling'
> > bios, that were split off, and then any remaining parents and ancestors.
>
> IMHO, that is
On Fri, Jul 8, 2016 at 6:07 AM, NeilBrown wrote:
> On Thu, Jul 07 2016, Lars Ellenberg wrote:
>
>> On Thu, Jul 07, 2016 at 03:35:48PM +1000, NeilBrown wrote:
>>> On Wed, Jun 22 2016, Lars Ellenberg wrote:
>>>
>>> > For a long time, generic_make_request() converts recursion into
>>> > iteration by
On Fri, Jul 08 2016, Lars Ellenberg wrote:
> On Fri, Jul 08, 2016 at 08:07:52AM +1000, NeilBrown wrote:
>> Before I introduced the recursion limiting, requests were handled as an
>> in-order tree walk. The code I wrote tried to preserve that but didn't
>> for several reasons. I think we need to
On Fri, Jul 08, 2016 at 08:07:52AM +1000, NeilBrown wrote:
> Before I introduced the recursion limiting, requests were handled as an
> in-order tree walk. The code I wrote tried to preserve that but didn't
> for several reasons. I think we need to restore the original in-order
> walk because it m
On Thu, Jul 07 2016, Mike Snitzer wrote:
> On Thu, Jul 07 2016 at 1:35am -0400,
> NeilBrown wrote:
>
>> On Wed, Jun 22 2016, Lars Ellenberg wrote:
>>
>> > For a long time, generic_make_request() converts recursion into
>> > iteration by queuing recursive arguments on current->bio_list.
>> >
>>
On Thu, Jul 07 2016, Lars Ellenberg wrote:
> On Thu, Jul 07, 2016 at 03:35:48PM +1000, NeilBrown wrote:
>> On Wed, Jun 22 2016, Lars Ellenberg wrote:
>>
>> > For a long time, generic_make_request() converts recursion into
>> > iteration by queuing recursive arguments on current->bio_list.
>> >
>>
On Wed, Jun 22 2016 at 4:22am -0400,
Lars Ellenberg wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for stacking drivers,
> the top-most driver would take the originally submitted bi
On Thu, Jul 7, 2016 at 4:03 PM, Lars Ellenberg
wrote:
> On Wed, Jul 06, 2016 at 11:57:51PM +0800, Ming Lei wrote:
>> > my suggestion
>> >
>> > generic_make_request(bio_orig)
>> > NULLin-flight=0
>> > bio_origempty in-flight=0
>> >
change the order in which stacked bios are processed
> > wrt the way it used to be since 2007 (my suggestion as is does not).
> >
> > Which may change performance metrics.
> > It may even improve some of them,
> > or maybe it does nothing, but we don't know.
> &
On Thu, Jul 07 2016 at 1:35am -0400,
NeilBrown wrote:
> On Wed, Jun 22 2016, Lars Ellenberg wrote:
>
> > For a long time, generic_make_request() converts recursion into
> > iteration by queuing recursive arguments on current->bio_list.
> >
> > This is convenient for stacking drivers,
> > the to
be since 2007 (my suggestion as is does not).
>
> Which may change performance metrics.
> It may even improve some of them,
> or maybe it does nothing, but we don't know.
>
> Thanks,
>
> Lars
>
>From 73254eae63786aca0af10e42e5b41465c90d8da8 Mon Sep 17 00:00:0
On Wed, Jul 06, 2016 at 11:57:51PM +0800, Ming Lei wrote:
> > my suggestion
> >
> > generic_make_request(bio_orig)
> > NULLin-flight=0
> > bio_origempty in-flight=0
> > qA->make_request_fn(bio_orig)
> > blk_queue_split()
> > res
On Thu, Jul 07, 2016 at 03:35:48PM +1000, NeilBrown wrote:
> On Wed, Jun 22 2016, Lars Ellenberg wrote:
>
> > For a long time, generic_make_request() converts recursion into
> > iteration by queuing recursive arguments on current->bio_list.
> >
> > This is convenient for stacking drivers,
> > the
On Wed, Jun 22 2016, Lars Ellenberg wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for stacking drivers,
> the top-most driver would take the originally submitted bio,
> and re-submit
On Wed, Jul 6, 2016 at 8:38 PM, Lars Ellenberg
wrote:
> On Mon, Jul 04, 2016 at 06:47:29PM +0800, Ming Lei wrote:
>> >> One clean solution may be to convert the loop of generic_make_request()
>> >> into the following way:
>> >>
>> >> do {
>> >> struct bio *splitted, *remainder = NULL;
>> >>
On Mon, Jul 04, 2016 at 06:47:29PM +0800, Ming Lei wrote:
> >> One clean solution may be to convert the loop of generic_make_request()
> >> into the following way:
> >>
> >> do {
> >> struct bio *splitted, *remainder = NULL;
> >> struct request_queue *q = bdev_get_queue(bio->bi_bdev);
> >>
On Mon, Jul 4, 2016 at 4:20 PM, Lars Ellenberg
wrote:
> On Sat, Jul 02, 2016 at 06:28:29PM +0800, Ming Lei wrote:
>> The idea looks good, but not sure it can cover all cases of
>> dm over brbd or brbd over dm and maintaining two lists
>> becomes too complicated.
>>
>> One clean solution may be to
On Sat, Jul 02, 2016 at 06:28:29PM +0800, Ming Lei wrote:
> The idea looks good, but not sure it can cover all cases of
> dm over brbd or brbd over dm and maintaining two lists
> becomes too complicated.
>
> One clean solution may be to convert the loop of generic_make_request()
> into the followi
On Wed, Jun 22, 2016 at 4:22 PM, Lars Ellenberg
wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for stacking drivers,
> the top-most driver would take the originally submitted bio,
> an
On Tue, Jun 28, 2016 at 4:45 PM, Lars Ellenberg
wrote:
> On Sat, Jun 25, 2016 at 05:30:29PM +0800, Ming Lei wrote:
>> On Fri, Jun 24, 2016 at 10:27 PM, Lars Ellenberg
>> wrote:
>> > On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote:
>> >> >
>> >> > This is not a theoretical problem.
>> >>
On Sat, Jun 25, 2016 at 05:30:29PM +0800, Ming Lei wrote:
> On Fri, Jun 24, 2016 at 10:27 PM, Lars Ellenberg
> wrote:
> > On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote:
> >> >
> >> > This is not a theoretical problem.
> >> > At least int DRBD, and an unfortunately high IO concurrency wr
On Fri, Jun 24, 2016 at 11:15:47AM -0400, Mike Snitzer wrote:
> On Fri, Jun 24 2016 at 10:27am -0400,
> Lars Ellenberg wrote:
>
> > On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote:
> > > >
> > > > This is not a theoretical problem.
> > > > At least int DRBD, and an unfortunately high IO
On Fri, Jun 24, 2016 at 10:27 PM, Lars Ellenberg
wrote:
> On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote:
>> >
>> > This is not a theoretical problem.
>> > At least int DRBD, and an unfortunately high IO concurrency wrt. the
>> > "max-buffers" setting, without this patch we have a reprod
On Fri, Jun 24 2016 at 10:27am -0400,
Lars Ellenberg wrote:
> On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote:
> > >
> > > This is not a theoretical problem.
> > > At least int DRBD, and an unfortunately high IO concurrency wrt. the
> > > "max-buffers" setting, without this patch we have
On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote:
> >
> > This is not a theoretical problem.
> > At least int DRBD, and an unfortunately high IO concurrency wrt. the
> > "max-buffers" setting, without this patch we have a reproducible deadlock.
>
> Is there any log about the deadlock? And
On Wed, Jun 22, 2016 at 4:22 PM, Lars Ellenberg
wrote:
> For a long time, generic_make_request() converts recursion into
> iteration by queuing recursive arguments on current->bio_list.
>
> This is convenient for stacking drivers,
> the top-most driver would take the originally submitted bio,
> an
For a long time, generic_make_request() converts recursion into
iteration by queuing recursive arguments on current->bio_list.
This is convenient for stacking drivers,
the top-most driver would take the originally submitted bio,
and re-submit a re-mapped version of it, or one or more clones,
or on
53 matches
Mail list logo
