From: Jens Axboe <axboe@kernel.dk>
To: Tero Kristo <tero.kristo@linux.intel.com>
Cc: hch@lst.de, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 2/2] blk-mq: add support for CPU latency limits
Date: Fri, 18 Oct 2024 08:21:17 -0600 [thread overview]
Message-ID: <cb9d65fe-47b9-4539-a8d0-9863e8ebf49f@kernel.dk> (raw)
In-Reply-To: <20241018075416.436916-3-tero.kristo@linux.intel.com>
On 10/18/24 1:30 AM, Tero Kristo wrote:
> @@ -2700,11 +2701,62 @@ static void blk_mq_plug_issue_direct(struct blk_plug *plug)
> static void __blk_mq_flush_plug_list(struct request_queue *q,
> struct blk_plug *plug)
> {
> + struct request *req, *next;
> + struct blk_mq_hw_ctx *hctx;
> + int cpu;
> +
> if (blk_queue_quiesced(q))
> return;
> +
> + rq_list_for_each_safe(&plug->mq_list, req, next) {
> + hctx = req->mq_hctx;
> +
> + if (next && next->mq_hctx == hctx)
> + continue;
> +
> + if (q->disk->cpu_lat_limit < 0)
> + continue;
> +
> + hctx->last_active = jiffies + msecs_to_jiffies(q->disk->cpu_lat_timeout);
> +
> + if (!hctx->cpu_lat_limit_active) {
> + hctx->cpu_lat_limit_active = true;
> + for_each_cpu(cpu, hctx->cpumask) {
> + struct dev_pm_qos_request *qos;
> +
> + qos = per_cpu_ptr(hctx->cpu_lat_qos, cpu);
> + dev_pm_qos_add_request(get_cpu_device(cpu), qos,
> + DEV_PM_QOS_RESUME_LATENCY,
> + q->disk->cpu_lat_limit);
> + }
> + schedule_delayed_work(&hctx->cpu_latency_work,
> + msecs_to_jiffies(q->disk->cpu_lat_timeout));
> + }
> + }
> +
This is, quite literally, and insane amount of cycles to add to the hot
issue path. You're iterating each request in the list, and then each CPU
in the mask of the hardware context for each request.
This just won't fly, not at all. Like the previous feedback, please
figure out a way to make this cheaper. This means don't iterate a bunch
of stuff.
Outside of that, lots of styling issues here too, but none of that
really matters until the base mechanism is at least half way sane.
--
Jens Axboe
next prev parent reply other threads:[~2024-10-18 14:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 7:30 [PATCHv2 0/2] blk-mq: add CPU latency limit control Tero Kristo
2024-10-18 7:30 ` [PATCHv2 1/2] block/genhd: add sysfs knobs for the CPU latency PM QoS settings Tero Kristo
2024-10-18 7:30 ` [PATCHv2 2/2] blk-mq: add support for CPU latency limits Tero Kristo
2024-10-18 14:21 ` Jens Axboe [this message]
2024-10-23 13:26 ` Tero Kristo
2024-10-23 13:48 ` Jens Axboe
2024-10-23 14:06 ` [PATCH v3 " Tero Kristo
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=cb9d65fe-47b9-4539-a8d0-9863e8ebf49f@kernel.dk \
--to=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tero.kristo@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox