Re: [dm-devel] [Drbd-dev] [PATCH 23/27] drbd: make intelligent use of blkdev_issue_zeroout

2018-01-16 Thread Lars Ellenberg
On Mon, Jan 15, 2018 at 10:07:38AM -0500, Mike Snitzer wrote: > > See also: > > https://www.redhat.com/archives/dm-devel/2017-March/msg00213.html > > https://www.redhat.com/archives/dm-devel/2017-March/msg00226.html > > Right, now that you mention it it is starting to ring a bell (especially >

Re: [dm-devel] [Drbd-dev] [PATCH 23/27] drbd: make intelligent use of blkdev_issue_zeroout

2018-01-15 Thread Lars Ellenberg
anyways *: provisioned, some arbitrary data 0: explicitly zeroed: |gran|ular|ity |||| ||||| to|-be-|zero|ed |**00|||00**| (leave unallocated blocks alone, de-allocate full blocks just like with discard, explicitly zero unaligned head and tail) O

Re: [dm-devel] [Drbd-dev] [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

2017-03-30 Thread Lars Ellenberg
On Thu, Mar 30, 2017 at 01:44:09PM +0200, Christoph Hellwig wrote: > On Thu, Mar 30, 2017 at 12:06:41PM +0200, Lars Ellenberg wrote: > > On Thu, Mar 23, 2017 at 10:33:40AM -0400, Christoph Hellwig wrote: > > > It seems like DRBD assumes its on the wire TRIM request always

Re: [dm-devel] [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

2017-03-30 Thread Lars Ellenberg
On Thu, Mar 23, 2017 at 10:33:40AM -0400, Christoph Hellwig wrote: > It seems like DRBD assumes its on the wire TRIM request always zeroes data. > Use that fact to implement REQ_OP_WRITE_ZEROES. > > XXX: will need a careful audit from the drbd team! Thanks, this one looks ok to me. The real

Re: [dm-devel] RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

2017-03-23 Thread Lars Ellenberg
On Thu, Mar 23, 2017 at 01:02:22PM -0400, Mike Snitzer wrote: > On Thu, Mar 23 2017 at 11:54am -0400, > Lars Ellenberg <lars.ellenb...@linbit.com> wrote: > > > On Thu, Mar 23, 2017 at 10:33:18AM -0400, Christoph Hellwig wrote: > > > This series makes REQ_OP_WRITE_Z

Re: [dm-devel] [PATCH v2] blk: improve order of bio handling in generic_make_request()

2017-03-10 Thread Lars Ellenberg
On Fri, Mar 10, 2017 at 04:07:58PM +0100, Jack Wang wrote: > On 10.03.2017 15:55, Mikulas Patocka wrote: > > On Fri, 10 Mar 2017, Mike Snitzer wrote: > >> On Fri, Mar 10 2017 at 7:34am -0500, > >> Lars Ellenberg <lars.ellenb...@linbit.com> wrote: > >>

Re: [dm-devel] [PATCH v2] blk: improve order of bio handling in generic_make_request()

2017-03-10 Thread Lars Ellenberg
> --- a/block/blk-core.c > +++ b/block/blk-core.c > @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio) > */ > blk_qc_t generic_make_request(struct bio *bio) > { > - struct bio_list bio_list_on_stack; > + /* > +* bio_list_on_stack[0] contains bios submitted

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

2017-01-07 Thread Lars Ellenberg
e. > > You probably don't want to use "fs_bio_set" either - a target-local > pool would be best. > > NeilBrown Which is pretty much what I suggested in this thread back in July already, see below. Cheers, Lars On Tue, Jul 19, 2016 at 11:00:24AM +0200, Lars Ellenbe

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

2016-12-23 Thread Lars Ellenberg
h it. Thanks for the bump. Lars On 07/11/2016 04:10 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-mo

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

2016-07-19 Thread Lars Ellenberg
On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote: > On Tue, Jul 12 2016 at 10:18pm -0400, > Eric Wheeler <bca...@lists.ewheeler.net> wrote: > > > On Tue, 12 Jul 2016, NeilBrown wrote: > > > > > On Tue, Jul 12 2016, Lars Ellenberg wrote: > >

Re: [dm-devel] [PATCH 1/1] block: fix blk_queue_split() resource exhaustion

2016-07-11 Thread Lars Ellenberg
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 -- dm-devel mailing list dm-devel@redhat.com

[dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

2016-07-11 Thread Lars Ellenberg
el bios first, and "sibling" bios of the same level in "natural" order. Signed-off-by: Lars Ellenberg <lars.ellenb...@linbit.com> Signed-off-by: Roland Kammerer <roland.kamme...@linbit.com> --- block/bio.c | 20 +++ block/blk-core

[dm-devel] [PATCH 1/1] block: fix blk_queue_split() resource exhaustion

2016-07-08 Thread Lars Ellenberg
el bios first, and "sibling" bios of the same level in "natural" order. Signed-off-by: Lars Ellenberg <lars.ellenb...@linbit.com> Signed-off-by: Roland Kammerer <roland.kamme...@linbit.com> --- block/bio.c | 27 + block/blk-core

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-07-08 Thread Lars Ellenberg
g, though. > > :-) neither "remainder" or "recursion" seem like brilliant names to me, > but I don't have anything better to suggest. Naming is hard! > As long as a comment explains the name clearly I could cope with X and Y. ... > I think we just might be in violent agreement. I thought so, too :-) Should I merge both patches, rename to ".queue" and ".tmp", and submit for inclusion? Lars Ellenberg -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-07-08 Thread Lars Ellenberg
bio(l=1,a,remainder), bio(l=1,b), bio(l=1,c), ..., bio(l=0,remainder_1) ] .recursion = [] ... process away ... until back at l=0 .incoming = [ bio(l=0,remainder_1) ] .recursion = [] potentially split further .incoming = [ bio(l=0,now_2), bio(l=0,remainder_2) ] .recursion = [] rinse, repeat. Thanks, Lars Ellenberg -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-07-07 Thread Lars Ellenberg
On Thu, Jul 07, 2016 at 10:16:16AM +0200, 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->

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-07-07 Thread Lars Ellenberg
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 i

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-07-07 Thread Lars Ellenberg
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() > >

Re: [dm-devel] [PATCH 0/3] offload bios to a thread

2016-07-04 Thread Lars Ellenberg
On Thu, Jun 30, 2016 at 07:15:18PM -0400, Mike Snitzer wrote: > > Lars, please feel free to see if this set addresses the similar deadlock > > you saw/fixed with drbd. I'm pretty sure it will help, but will confirm. > > We need to converge on an acceptable fix for > > this problem -- preferably

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-06-28 Thread Lars Ellenberg
On Sat, Jun 25, 2016 at 05:30:29PM +0800, Ming Lei wrote: > On Fri, Jun 24, 2016 at 10:27 PM, Lars Ellenberg > <lars.ellenb...@linbit.com> wrote: > > On Fri, Jun 24, 2016 at 07:36:57PM +0800, Ming Lei wrote: > >> > > >> > This is not a the

Re: [dm-devel] [RFC] block: fix blk_queue_split() resource exhaustion

2016-06-24 Thread Lars Ellenberg
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