From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Tim Chen <tim.c.chen@linux.intel.com>,
Juri Lelli <juri.lelli@redhat.com>,
Andrew Theurer <atheurer@redhat.com>,
Joe Mario <jmario@redhat.com>, Sebastian Jug <sejug@redhat.com>,
Frederic Weisbecker <frederic@kernel.org>,
Bart Van Assche <bvanassche@acm.org>, Tejun Heo <tj@kernel.org>,
ming.lei@redhat.com
Subject: Re: [PATCH V4] blk-mq: don't schedule block kworker on isolated CPUs
Date: Thu, 21 Mar 2024 20:49:23 +0800 [thread overview]
Message-ID: <Zfws04M0p3QUPmPJ@fedora> (raw)
In-Reply-To: <20240320023446.882006-1-ming.lei@redhat.com>
On Wed, Mar 20, 2024 at 10:34:46AM +0800, Ming Lei wrote:
> Kernel parameter of `isolcpus=` or 'nohz_full=' are used to isolate CPUs
> for specific task, and it isn't expected to let block IO disturb these CPUs.
> blk-mq kworker shouldn't be scheduled on isolated CPUs. Also if isolated
> CPUs is run for blk-mq kworker, long block IO latency can be caused.
>
> Kernel workqueue only respects CPU isolation for WQ_UNBOUND, for bound
> WQ, the responsibility is on user because CPU is specified as WQ API
> parameter, such as mod_delayed_work_on(cpu), queue_delayed_work_on(cpu)
> and queue_work_on(cpu).
>
> So not run blk-mq kworker on isolated CPUs by removing isolated CPUs
> from hctx->cpumask. Meantime use queue map to check if all CPUs in this
> hw queue are offline instead of hctx->cpumask, this way can avoid any
> cost in fast IO code path, and is safe since hctx->cpumask are only
> used in the two cases.
>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Andrew Theurer <atheurer@redhat.com>
> Cc: Joe Mario <jmario@redhat.com>
> Cc: Sebastian Jug <sejug@redhat.com>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Bart Van Assche <bvanassche@acm.org>
> Cc: Tejun Heo <tj@kernel.org>
> Tested-by: Joe Mario <jmario@redhat.com>
> Signed-off-by: Ming Lei <ming.lei@redhat.com>
> ---
> V4:
> - improve comment & commit log as suggested by Tim
Hello Jens, Tejun and Guys,
This patch fixes one issue in OpenShift low latency environment, I appreciate
you may take a look at the patch and merge it if you are fine.
Thanks,
Ming
next prev parent reply other threads:[~2024-03-21 12:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 2:34 [PATCH V4] blk-mq: don't schedule block kworker on isolated CPUs Ming Lei
2024-03-21 12:49 ` Ming Lei [this message]
2024-03-21 17:07 ` Jens Axboe
2024-03-22 1:10 ` 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=Zfws04M0p3QUPmPJ@fedora \
--to=ming.lei@redhat.com \
--cc=atheurer@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=frederic@kernel.org \
--cc=jmario@redhat.com \
--cc=juri.lelli@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sejug@redhat.com \
--cc=tim.c.chen@linux.intel.com \
--cc=tj@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.