All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Jeffle Xu <jefflexu@linux.alibaba.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org
Subject: Re: [RFC] block: enqueue splitted bios into same cpu
Date: Fri, 11 Sep 2020 19:01:01 +0800	[thread overview]
Message-ID: <20200911110101.GA143560@T590> (raw)
In-Reply-To: <20200911032958.125068-1-jefflexu@linux.alibaba.com>

On Fri, Sep 11, 2020 at 11:29:58AM +0800, Jeffle Xu wrote:
> Splitted bios of one source bio can be enqueued into different CPU since
> the submit_bio() routine can be preempted or fall asleep. However this
> behaviour can't work well with iopolling.

Do you have user visible problem wrt. io polling? If yes, can you
provide more details?

> 
> Currently block iopolling only polls the hardwar queue of the input bio.
> If one bio is splitted to several bios, one (bio 1) of which is enqueued
> into CPU A, while the others enqueued into CPU B, then the polling of bio 1
> will cotinuously poll the hardware queue of CPU A, though the other
> splitted bios may be in other hardware queues.

If it is guaranteed that the returned cookie is from bio 1, poll is
supposed to work as expected, since bio 1 is the chained head of these
bios, and the whole fs bio can be thought as done when bio1 .end_bio
is called.

> 
> The iopolling logic has no idea if the input bio is splitted bio, or if
> it has other splitted siblings. Thus ensure that all splitted bios are
> enqueued into one CPU at the beginning.

Yeah, that is why io poll can't work on DM.

> 
> This is only one RFC patch and it is not complete since dm/mq-scheduler
> have not been considered yet. Please let me know if it is on the correct
> direction or not.
> 
> Besides I have one question on the split routine. Why the split routine
> is implemented in a recursive style? Why we can't split the bio one time
> and then submit the *already splitted* bios one by one?

Forward progress has to be provided on new splitted bio allocation which
is from same bio_set.


Thanks, 
Ming


  reply	other threads:[~2020-09-11 11:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11  3:29 [RFC] block: enqueue splitted bios into same cpu Jeffle Xu
2020-09-11 11:01 ` Ming Lei [this message]
2020-09-11 11:46   ` JeffleXu
     [not found]   ` <e787faa8-d31f-04e7-f722-5013a52dc8ab@linux.alibaba.com>
2020-09-13 14:00     ` Ming Lei
2020-09-22  4:43       ` JeffleXu
2020-09-22 11:56         ` Ming Lei
2020-09-22 12:19           ` JeffleXu
2020-09-23  7:15             ` 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=20200911110101.GA143560@T590 \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=jefflexu@linux.alibaba.com \
    --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.