From: Christoph Hellwig <hch@lst.de>
To: Xiongfeng Wang <wangxiongfeng@huaweicloud.com>
Cc: axboe@kernel.dk, hch@lst.de, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, wangxiongfeng2@huawei.com,
liwei391@huawei.com, wangkefeng.wang@huawei.com
Subject: Re: [RFC PATCH] blk-mq: avoid housekeeping CPUs scheduling a worker on a non-housekeeping CPU
Date: Thu, 23 Feb 2023 16:06:24 +0100 [thread overview]
Message-ID: <20230223150624.GA29739@lst.de> (raw)
In-Reply-To: <20230223074826.3782643-1-wangxiongfeng@huaweicloud.com>
On Thu, Feb 23, 2023 at 03:48:26PM +0800, Xiongfeng Wang wrote:
> From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>
> When NOHZ_FULL is enabled, such as in HPC situation, CPUs are divided
> into housekeeping CPUs and non-housekeeping CPUs. Non-housekeeping CPUs
> are NOHZ_FULL CPUs and are often monopolized by the userspace process,
> such HPC application process. Any sort of interruption is not expected.
>
> blk_mq_hctx_next_cpu() selects each cpu in 'hctx->cpumask' alternately
> to schedule the work thread blk_mq_run_work_fn(). When 'hctx->cpumask'
> contains housekeeping CPU and non-housekeeping CPU at the same time, a
> housekeeping CPU, which want to request a IO, may schedule a worker on a
> non-housekeeping CPU. This may affect the performance of the userspace
> application running on non-housekeeping CPUs.
>
> So let's just schedule the worker thread on the current CPU when the
> current CPU is housekeeping CPU.
This looks like an odd non-systemic bandaid. Shouldn't we have a more
generic way nothing ever gets onto these non-housekeeping CPUs by making
sure they never show up in the cpumask, and never get completion IPIs?
next prev parent reply other threads:[~2023-02-23 15:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 7:48 [RFC PATCH] blk-mq: avoid housekeeping CPUs scheduling a worker on a non-housekeeping CPU Xiongfeng Wang
2023-02-23 15:06 ` Christoph Hellwig [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-02-10 9:35 Xiongfeng Wang
2022-02-15 2:29 ` Xiongfeng Wang
2022-02-15 4:37 ` Ming Lei
2022-02-15 9:32 ` Xiongfeng Wang
2022-02-15 9:38 ` Xiongfeng Wang
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=20230223150624.GA29739@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liwei391@huawei.com \
--cc=wangkefeng.wang@huawei.com \
--cc=wangxiongfeng2@huawei.com \
--cc=wangxiongfeng@huaweicloud.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 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.