From: Keith Busch <kbusch@kernel.org>
To: Andrzej Jakowski <andrzej.jakowski@linux.intel.com>
Cc: axboe@kernel.dk, song@kernel.org, linux-block@vger.kernel.org,
linux-raid@vger.kernel.org,
Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Subject: Re: [PATCH v2 2/2] md: enable io polling
Date: Sat, 15 Feb 2020 04:25:26 +0900 [thread overview]
Message-ID: <20200214192526.GA10991@redsun51.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <f516e2b2-1988-03ca-f966-5f26771717ff@linux.intel.com>
On Thu, Feb 13, 2020 at 01:19:42PM -0700, Andrzej Jakowski wrote:
> On 2/12/20 2:42 PM, Keith Busch wrote:
> > Okay, that's a nice subtlety. But it means the original caller gets the
> > cookie from the last submission in the chain. If md recieves a single
> > request that has to be split among more than one member disk, the cookie
> > you're using to control the polling is valid only for one of the
> > request_queue's and may break others.
>
> Correct, I agree that it is an issue. I can see at least two ways how to solve it:
> 1. Provide a mechanism in md accounting for outstanding IOs, storing cookie information
> for them. md_poll() will then use valid cookie's
> 2. Provide similar mechanism abstracted for stackable block devices and block layer could
> handle completions for subordinate bios in an abstracted way in blk_poll() routine.
> How do you Guys see this going?
Honestly, I don't see how this is can be successful without a more
significant change than you may be anticipating. I'd be happy to hear if
there's a better solution, but here's what I'm thinking:
You'd need each stacking layer to return a cookie that its poll function
can turn into a list of { request_queue, blk_qc_t } tuples for each bio
the stacking layer created so that it can chain the poll request to the
next layers.
The problems are that the stacking layers don't get a cookie for the
bio's it submits from within the same md_make_request() context. Even if
you could get the cookie associated with those bios, you either allocate
more memory to track these things, or need polling bio list link fields
added 'struct bio', neither of which seem very appealing.
Do you have a better way in mind?
next prev parent reply other threads:[~2020-02-14 19:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 19:17 [PATCH v2 0/2] Enable polling on stackable devices Andrzej Jakowski
2020-02-11 19:17 ` [PATCH v2 1/2] block: reintroduce polling on bio level Andrzej Jakowski
2020-02-11 19:17 ` [PATCH v2 2/2] md: enable io polling Andrzej Jakowski
2020-02-11 21:13 ` Keith Busch
2020-02-12 21:00 ` Andrzej Jakowski
2020-02-12 21:42 ` Keith Busch
2020-02-13 20:19 ` Andrzej Jakowski
2020-02-14 19:25 ` Keith Busch [this message]
2020-02-21 15:25 ` Andrzej Jakowski
2020-02-21 16:34 ` Keith Busch
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=20200214192526.GA10991@redsun51.ssa.fujisawa.hgst.com \
--to=kbusch@kernel.org \
--cc=andrzej.jakowski@linux.intel.com \
--cc=artur.paszkiewicz@intel.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).