From: Ming Lei <ming.lei@redhat.com>
To: Daniel Wagner <dwagner@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, John Garry <john.garry@huawei.com>,
Bart Van Assche <bvanassche@acm.org>,
Hannes Reinecke <hare@suse.com>, Christoph Hellwig <hch@lst.de>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH V6 0/8] blk-mq: improvement CPU hotplug
Date: Wed, 8 Apr 2020 21:25:13 +0800 [thread overview]
Message-ID: <20200408132513.GA366654@localhost.localdomain> (raw)
In-Reply-To: <20200408124017.g6wizq5bljzwb2gq@beryllium.lan>
Hi Daniel,
On Wed, Apr 08, 2020 at 02:40:17PM +0200, Daniel Wagner wrote:
> Hi Ming,
>
> On Tue, Apr 07, 2020 at 05:28:53PM +0800, Ming Lei wrote:
> > Hi,
> >
> > Thomas mentioned:
> > "
> > That was the constraint of managed interrupts from the very beginning:
> >
> > The driver/subsystem has to quiesce the interrupt line and the associated
> > queue _before_ it gets shutdown in CPU unplug and not fiddle with it
> > until it's restarted by the core when the CPU is plugged in again.
> > "
> >
> > But no drivers or blk-mq do that before one hctx becomes inactive(all
> > CPUs for one hctx are offline), and even it is worse, blk-mq stills tries
> > to run hw queue after hctx is dead, see blk_mq_hctx_notify_dead().
> >
> > This patchset tries to address the issue by two stages:
> >
> > 1) add one new cpuhp state of CPUHP_AP_BLK_MQ_ONLINE
> >
> > - mark the hctx as internal stopped, and drain all in-flight requests
> > if the hctx is going to be dead.
> >
> > 2) re-submit IO in the state of CPUHP_BLK_MQ_DEAD after the hctx becomes dead
> >
> > - steal bios from the request, and resubmit them via generic_make_request(),
> > then these IO will be mapped to other live hctx for dispatch
> >
> > Please comment & review, thanks!
>
> FWIW, I've stress test this series by running the stress-cpu-hotplug
> with a fio workload in the background. Nothing exploded, all just
> worked fine.
Thanks for your test!
Especially this patch changes flush & passthrough IO handling during
CPU hotplug, if possible, please include the two kinds of background IO
when running cpu hotplug test.
BTW, I verified the patches by running 'dbench -s 64' & concurrent NVMe
user IO during cpu hotplug, looks it works fine.
Also there is one known performance drop issue reported by John, which has
been addressed in the following link:
https://github.com/ming1/linux/commit/1cfbe1b2f7fd7085bc86e09c6443a20e89142975
Thanks,
Ming
prev parent reply other threads:[~2020-04-08 13:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 9:28 [PATCH V6 0/8] blk-mq: improvement CPU hotplug Ming Lei
2020-04-07 9:28 ` [PATCH V6 1/8] blk-mq: assign rq->tag in blk_mq_get_driver_tag Ming Lei
2020-04-07 17:14 ` Christoph Hellwig
2020-04-08 1:38 ` Ming Lei
2020-04-07 9:28 ` [PATCH V6 2/8] blk-mq: add new state of BLK_MQ_S_INACTIVE Ming Lei
2020-04-07 17:14 ` Christoph Hellwig
2020-04-07 9:28 ` [PATCH V6 3/8] blk-mq: prepare for draining IO when hctx's all CPUs are offline Ming Lei
2020-04-07 9:28 ` [PATCH V6 4/8] blk-mq: stop to handle IO and drain IO before hctx becomes inactive Ming Lei
2020-04-07 9:28 ` [PATCH V6 5/8] block: add blk_end_flush_machinery Ming Lei
2020-04-07 9:28 ` [PATCH V6 6/8] blk-mq: re-submit IO in case that hctx is inactive Ming Lei
2020-04-07 9:29 ` [PATCH V6 7/8] blk-mq: handle requests dispatched from IO scheduler in case of inactive hctx Ming Lei
2020-04-07 9:29 ` [PATCH V6 8/8] block: deactivate hctx when the hctx is actually inactive Ming Lei
2020-04-08 12:40 ` [PATCH V6 0/8] blk-mq: improvement CPU hotplug Daniel Wagner
2020-04-08 13:01 ` John Garry
2020-04-08 13:10 ` Daniel Wagner
2020-04-08 13:29 ` John Garry
2020-04-08 15:14 ` Daniel Wagner
2020-04-08 16:56 ` John Garry
2020-04-08 13:25 ` Ming Lei [this message]
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=20200408132513.GA366654@localhost.localdomain \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=dwagner@suse.de \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.