From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, dm-devel@redhat.com
Subject: Re: [PATCH 2/5] block: make bio_inc_remaining() interface accessible again
Date: Fri, 6 May 2016 11:57:15 -0400 [thread overview]
Message-ID: <20160506155715.GB672@redhat.com> (raw)
In-Reply-To: <20160506152535.GA6738@lst.de>
On Fri, May 06 2016 at 11:25am -0400,
Christoph Hellwig <hch@lst.de> wrote:
> On Thu, May 05, 2016 at 11:54:22AM -0400, Mike Snitzer wrote:
> > Commit 326e1dbb57 ("block: remove management of bi_remaining when
> > restoring original bi_end_io") made bio_inc_remaining() private to bio.c
> > because the only use-case that made sense was confined to the
> > bio_chain() interface.
> >
> > Since that time DM thinp went on to use bio_chain() in its relatively
> > complex implementation of async discard support. That implementation,
> > even when converted over to use the new async __blkdev_issue_discard()
> > interface, depends on deferred completion of the original discard bio --
> > which is most appropriately implemented using bio_inc_remaining().
>
> Can you explain that code flow to me? I still fail to why exactly
> dm-thinp (and only dm-thinp) needs this. Maybe start by pointing me
> to the additional bio_endio that pairs with the bio_inc_remaining
> call.
If you look at the latest code here:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-4.7
dm-thin.c:break_up_discard_bio()'s bio_inc_remaining() is paired with
dm-thin.c:end_discard()'s bio_endio()
But the flow is:
-> process_discard_cell_passdown
-> break_up_discard_bio (per-mapping reference taken on original discard bio)
-> bio_endio(original discard bio) -- cleanest place to complete
it.. but doing so here requires extra references on that discard
bio because we must wait for the N mappings and associated
sub-discard bios to be chained, issued, and completed
... wait for associated sub-discard mappings to quiesce and become "prepared"...
-> process_prepared_discard_passdown (bio-chains aren't constructed until here)
-> passdown_double_checking_shared_status (iterates over each mappings' subset of the original discard)
-> __blkdev_issue_discard
-> bio_endio (per-mapping reference, taken in break_up_discard_bio, is dropped)
> > All said, bio_inc_remaining() should really only be used in conjunction
> > with bio_chain(). It isn't intended for generic bio reference counting.
>
> It's obviously used outside bio_chain in dm-thinp, so this sentence
> doesn't make too much sense to me.
It is used in conjunction with supporting thinp's use of bio_chain(),
via __blkdev_issue_discard, but yeah I can see why you think they aren't
related.
next prev parent reply other threads:[~2016-05-06 15:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 15:54 [PATCH 0/5] dm thin: adapt code to use new async __blkdev_issue_discard Mike Snitzer
2016-05-05 15:54 ` [PATCH v2 1/5] block: reinstate early return of -EOPNOTSUPP from blkdev_issue_discard Mike Snitzer
2016-05-06 16:04 ` Christoph Hellwig
2016-05-05 15:54 ` [PATCH 2/5] block: make bio_inc_remaining() interface accessible again Mike Snitzer
2016-05-06 15:25 ` Christoph Hellwig
2016-05-06 15:56 ` Christoph Hellwig
2016-05-06 16:19 ` Mike Snitzer
2016-05-06 16:27 ` Christoph Hellwig
2016-05-06 16:46 ` Joe Thornber
2016-05-06 16:30 ` Joe Thornber
2016-05-06 16:43 ` Christoph Hellwig
2016-05-06 15:57 ` Mike Snitzer [this message]
2016-05-05 15:54 ` [PATCH 3/5] dm thin: remove __bio_inc_remaining() and switch to using bio_inc_remaining() Mike Snitzer
2016-05-05 15:54 ` [PATCH 4/5] dm thin: use __blkdev_issue_discard for async discard support Mike Snitzer
2016-05-06 16:05 ` Christoph Hellwig
2016-05-05 15:54 ` [PATCH 5/5] dm thin: unroll issue_discard() to create longer discard bio chains Mike Snitzer
2016-05-06 16:12 ` Christoph Hellwig
2016-05-06 16:36 ` Joe Thornber
2016-05-06 16:44 ` Christoph Hellwig
2016-05-06 16:48 ` Joe Thornber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160506155715.GB672@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.