From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>, Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, linux-block@vger.kernel.org
Subject: Re: [PATCH v5 2/2] dm: support bio polling
Date: Mon, 7 Mar 2022 10:41:31 +0800 [thread overview]
Message-ID: <YiVw2y1eTcXrsdME@T590> (raw)
In-Reply-To: <89612542-0040-65bd-23bc-5bf8cac71f61@kernel.dk>
On Sun, Mar 06, 2022 at 07:25:11PM -0700, Jens Axboe wrote:
> On 3/6/22 7:20 PM, Ming Lei wrote:
> > On Sun, Mar 06, 2022 at 06:48:15PM -0700, Jens Axboe wrote:
> >> On 3/6/22 2:29 AM, Christoph Hellwig wrote:
> >>>> +/*
> >>>> + * Reuse ->bi_end_io as hlist head for storing all dm_io instances
> >>>> + * associated with this bio, and this bio's bi_end_io has to be
> >>>> + * stored in one of 'dm_io' instance first.
> >>>> + */
> >>>> +static inline struct hlist_head *dm_get_bio_hlist_head(struct bio *bio)
> >>>> +{
> >>>> + WARN_ON_ONCE(!(bio->bi_opf & REQ_DM_POLL_LIST));
> >>>> +
> >>>> + return (struct hlist_head *)&bio->bi_end_io;
> >>>> +}
> >>>
> >>> So this reuse is what I really hated. I still think we should be able
> >>> to find space in the bio by creatively shifting fields around to just
> >>> add the hlist there directly, which would remove the need for this
> >>> override and more importantly the quite cumbersome saving and restoring
> >>> of the end_io handler.
> >>
> >> If it's possible, then that would be preferable. But I don't think
> >> that's going to be easy to do...
> >
> > I agree, now basically there isn't gap inside bio, so either adding one
> > new field or reusing one existed field...
>
> There'd no amount of re-arranging that'll free up 8 bytes, that's just
> not happening. I'm not a huge fan of growing struct bio for that, and
> the oddity here is mostly (to me) that ->bi_end_io is the one overlayed.
> That would usually belong to the owner of the bio.
>
> Maybe some commenting would help?
OK, ->bi_end_io is safe because it is only called until the bio is
ended, so we can retrieve the list head and recover ->bi_end_io before
polling.
> Is bi_next available at this point?
The same bio can be re-submitted to block layer because of splitting, and
will be linked to current->bio_list[].
BTW, bio splitting can be very often for some dm target, that is why we
don't ignore bio splitting for dm polling.
Thanks,
Ming
next prev parent reply other threads:[~2022-03-07 2:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-05 2:08 [PATCH v5 0/2] block/dm: support bio polling Mike Snitzer
2022-03-05 2:08 ` [PATCH v5 1/2] block: add ->poll_bio to block_device_operations Mike Snitzer
2022-03-06 9:27 ` Christoph Hellwig
2022-03-05 2:08 ` [PATCH v5 2/2] dm: support bio polling Mike Snitzer
2022-03-06 9:29 ` Christoph Hellwig
2022-03-07 1:48 ` Jens Axboe
2022-03-07 2:20 ` Ming Lei
2022-03-07 2:25 ` Jens Axboe
2022-03-07 2:41 ` Ming Lei [this message]
2022-03-07 3:39 ` Ming Lei
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=YiVw2y1eTcXrsdME@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=snitzer@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox