From: sashiko-bot@kernel.org
To: "Yury Norov" <ynorov@nvidia.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH 6/7] virt: steal_governor: restart sampling immediately after CPU hotplug
Date: Fri, 13 Nov 2026 19:21:42 +0000 [thread overview]
Message-ID: <sashiko-outbox-213542@kernel.org> (raw)
In-Reply-To: <20261113184257.621707-7-ynorov@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] virt: steal_governor: deprecated system_wq use and workqueue
mismatch
--
commit 71c885eda2b0a72a307fd87b15575e6e5a4178ed
Author: Yury Norov <ynorov@nvidia.com>
virt: steal_governor: restart sampling immediately after CPU hotplug
This commit registers a CPU hotplug callback to invalidate the current
steal-time sample and immediately requeue the governor work when a CPU
goes online or offline.
> diff --git a/drivers/virt/steal_governor.c b/drivers/virt/steal_governor.c
> index c34d91267ec1d..f71dbf27e4a9d 100644
> --- a/drivers/virt/steal_governor.c
> +++ b/drivers/virt/steal_governor.c
[ ... ]
> @@ -217,6 +220,13 @@ static bool preferred_cpus_valid(void)
> return true;
> }
>
> +static int hotplug_callback(unsigned int cpu)
> +{
> + sg_ctx.sample_invalidated = true;
> + mod_delayed_work(system_wq, &sg_ctx.work, 0);
> + return 0;
> +}
> +
> static void steal_governor_loop(struct work_struct *work)
> {
> u64 curr_steal, delta_steal, delta_ns, steal_ratio;
> @@ -233,6 +243,11 @@ static void steal_governor_loop(struct work_struct *work)
> sg_ctx.steal = curr_steal;
> sg_ctx.time = now;
>
> + if (sg_ctx.sample_invalidated) {
> + sg_ctx.sample_invalidated = false;
> + goto requeue_work;
> + }
> +
> /*
> * steal_ratio = (delta_steal * 100*100)/(delta_ns * num_cpus())
> * To avoid possible overflow, divide the denominator early.
> @@ -254,11 +269,14 @@ static void steal_governor_loop(struct work_struct *work)
> return;
> }
>
> - schedule_delayed_work(&sg_ctx.work, sg_ctx.delay);
> +requeue_work:
> + mod_delayed_work(system_wq, &sg_ctx.work, sg_ctx.delay);
> }
[Severity: Medium]
Should both mod_delayed_work() calls use system_percpu_wq instead of
system_wq?
system_wq is allocated with __WQ_DEPRECATED, so queueing sg_ctx.work onto
it triggers a pr_warn_once() deprecation warning in __queue_work().
In addition, steal_governor_init() queues sg_ctx.work onto
system_percpu_wq via schedule_delayed_work(), which is a separate
workqueue_struct from system_wq. Because __queue_work() only enforces
cross-CPU non-reentrancy when worker->current_pwq->wq == wq, a hotplug
event during the first execution of steal_governor_loop() can queue
sg_ctx.work on a second CPU while it is still running on the first:
CPU0 (system_percpu_wq) CPU1 (hotplug)
steal_governor_loop()
guard(cpus_read_lock)()
(blocks on cpus_write_lock)
hotplug_callback()
sg_ctx.sample_invalidated = true
mod_delayed_work(system_wq, ..., 0)
(wq != current_pwq->wq, queues on CPU1)
cpus_write_unlock()
sg_ctx.sample_invalidated = false
...
steal_governor_loop()
guard(cpus_read_lock)()
(sample_invalidated is false, delta_ns ~ 0)
increase_preferred_cpus() <-- bogus sample
When the second worker runs right after the first finishes,
sample_invalidated has already been cleared and delta_ns is near zero,
yielding steal_ratio == 0 and calling increase_preferred_cpus()
prematurely.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261113184257.621707-2-ynorov@nvidia.com?part=6
next prev parent reply other threads:[~2026-11-13 19:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 18:42 [PATCH 0/7] Harden preferred CPUs management Yury Norov
2026-11-13 18:42 ` [PATCH 1/7] cpumask: add reset_preferred_cpumask() helper Yury Norov
2026-11-13 18:55 ` sashiko-bot
2026-11-13 18:42 ` [PATCH 2/7] sched: restore preferred CPUs when hotplug removes the last one Yury Norov
2026-11-13 19:12 ` sashiko-bot
2026-11-13 18:42 ` [PATCH 3/7] virt: steal_governor: remove the minimum elapsed-time check Yury Norov
2026-11-13 18:56 ` sashiko-bot
2026-11-13 18:42 ` [PATCH 4/7] virt: steal_governor: serialize sampling against CPU hotplug Yury Norov
2026-11-13 19:03 ` sashiko-bot
2026-11-13 18:42 ` [PATCH 5/7] virt: steal_governor: warn on unexpected preferred mask states Yury Norov
2026-11-13 19:06 ` sashiko-bot
2026-11-13 18:42 ` [PATCH 6/7] virt: steal_governor: restart sampling immediately after CPU hotplug Yury Norov
2026-11-13 19:21 ` sashiko-bot [this message]
2026-11-13 18:42 ` [PATCH 7/7] cpu: make preferred CPU policy writers mutually exclusive Yury Norov
2026-11-13 19:25 ` sashiko-bot
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=sashiko-outbox-213542@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=ynorov@nvidia.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.