Linux virtualization list
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Shrikanth Hegde" <sshegde@linux.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Eugenio Perez" <eperezma@redhat.com>,
	virtualization@lists.linux.dev
Subject: Re: [PATCH v14 07/13] sched/fair: Load balance only among preferred CPUs
Date: Mon, 28 Sep 2026 05:55:24 +0000	[thread overview]
Message-ID: <20260928055524.C14B11F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260928053728.797539-8-sshegde@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] sched: capacity mismatch in load balance due to restricted env->cpus
--

commit 614fa1366931a4c3a90955d4b7c85dd2e0e3bb49
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Subject: sched/fair: Load balance only among preferred CPUs

This commit restricts load balancing to preferred CPUs to avoid conflicting
with the tick's push task mechanism. It replaces cpu_active_mask with
cpu_preferred_mask during load balance CPU mask initialization and bails
out early in newidle balancing if the CPU is not preferred.

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 03206e15e6fe4..1c687c3c70f11 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -13467,7 +13467,7 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq,
>  	};
>  	bool need_unlock = false;
>  
> -	cpumask_and(cpus, sched_domain_span(sd), cpu_active_mask);
> +	cpumask_and(cpus, sched_domain_span(sd), cpu_preferred_mask);

[Severity: High]
Will this change create a capacity mismatch in the load balancer?

When env->cpus is restricted to cpu_preferred_mask here, update_sg_lb_stats()
will only aggregate group load for those preferred CPUs:

kernel/sched/fair.c:update_sg_lb_stats() {
    ...
    for_each_cpu_and(i, sched_group_span(group), env->cpus) {
        struct rq *rq = cpu_rq(i);
        unsigned long load = cpu_load(rq);

        sgs->group_load += load;
    ...
}

However, the group's capacity is set using the full capacity of all active
CPUs:

kernel/sched/fair.c:update_sg_lb_stats() {
    ...
    sgs->group_capacity = group->sgc->capacity;
    ...
}

Could the mismatch between the deflated group_load and the full group_capacity
artificially lower sgs->avg_load?

This phantom spare capacity might cause the load balancer to aggressively pull
tasks from other groups into the preferred CPUs of the destination group,
overloading them.

Can this also prevent tasks on non-preferred CPUs from ever being load
balanced?

kernel/sched/fair.c:sched_balance_find_src_rq() {
    ...
    for_each_cpu_and(i, sched_group_span(group), env->cpus) {
    ...
}

Because this loop uses env->cpus, the load balancer ignores non-preferred
CPUs entirely, even if they are overloaded.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928053728.797539-1-sshegde@linux.ibm.com?part=7

  reply	other threads:[~2026-09-28  5:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28  5:37 [PATCH v14 00/13] sched, steal_governor: Introduce preferred CPUs and steal-driven vCPU backoff Shrikanth Hegde
2026-09-28  5:37 ` [PATCH v14 01/13] sched/cputime: Add kcpustat_field_total helper Shrikanth Hegde
2026-09-28  5:54   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 02/13] cpumask: Introduce cpumask_intersects_and Shrikanth Hegde
2026-09-28  5:44   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 03/13] sched/docs: Document cpu_preferred_mask and Preferred CPU concept Shrikanth Hegde
2026-09-28  5:42   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 04/13] cpumask: Introduce cpu_preferred_mask Shrikanth Hegde
2026-09-28  5:46   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 05/13] sysfs: Add preferred CPU file Shrikanth Hegde
2026-09-28  5:47   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 06/13] sched/core: Try to use a preferred CPU in is_cpu_allowed Shrikanth Hegde
2026-09-28  6:00   ` sashiko-bot
2026-09-28  6:48     ` Shrikanth Hegde
2026-09-28  5:37 ` [PATCH v14 07/13] sched/fair: Load balance only among preferred CPUs Shrikanth Hegde
2026-09-28  5:55   ` sashiko-bot [this message]
2026-09-28  5:37 ` [PATCH v14 08/13] sched/core: Push current task from non preferred CPU Shrikanth Hegde
2026-09-28  5:56   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 09/13] sched/debug: Add migration stats due to non preferred CPUs Shrikanth Hegde
2026-09-28  5:48   ` sashiko-bot
2026-09-29 12:18   ` Nathan Chancellor
2026-09-29 12:43     ` Shrikanth Hegde
2026-09-29 14:57       ` Shrikanth Hegde
2026-09-28  5:37 ` [PATCH v14 10/13] virt: Introduce steal governor driver Shrikanth Hegde
2026-09-28  5:47   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 11/13] virt/steal_governor: Add control knobs for handling steal values Shrikanth Hegde
2026-09-28  5:46   ` sashiko-bot
2026-09-28  5:37 ` [PATCH v14 12/13] virt/steal_governor: Implement steal_governor policy loop Shrikanth Hegde
2026-09-28  5:51   ` sashiko-bot
2026-09-28  6:52     ` Shrikanth Hegde
2026-09-28  5:37 ` [PATCH v14 13/13] virt/steal_governor: Enable the driver Shrikanth Hegde
2026-09-28  5:48   ` 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=20260928055524.C14B11F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=eperezma@redhat.com \
    --cc=mst@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sshegde@linux.ibm.com \
    --cc=virtualization@lists.linux.dev \
    /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