[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87wm13bgd8.ffs@tglx>
Date: Tue, 27 Jan 2026 09:37:55 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Zhan Xusheng <zhanxusheng1024@...il.com>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
zhanxusheng1024@...il.com, zhanxusheng@...omi.com
Subject: Re: [PATCH v2] genirq/matrix: Clarify CPU selection logic
On Tue, Jan 27 2026 at 10:41, Zhan Xusheng wrote:
> The CPU selection logic in matrix_find_best_cpu() and
> matrix_find_best_cpu_managed() mixes eligibility checks with update
> conditions, making the actual selection criteria harder to reason
> about during review.
>
> Refactor both loops to separate the online check from the comparison
> itself and make the selection rules explicit. In
> matrix_find_best_cpu(), this is a pure readability change with no
> behavioral impact.
>
> In matrix_find_best_cpu_managed(), the refactoring also avoids updating
> best_cpu when CPUs have identical managed_allocated counts, removing an
> implicit tie-breaking behavior based on CPU iteration order.
... by replacing it with a different tie-breaking behaviour based on CPU
iteration order. What's the actual improvement here?
> The intended selection policy is unchanged, except that equal cases in
> the managed path no longer trigger redundant best_cpu updates.
You're doing two things at once. The selection logic change is
completely separate from the "polishing" and it's clearly documented
that functional changes have to be separated from others.
If your main objective is to adjust the tie-breaking logic, then you can
do that with a single character insertion plus a reasonable explanation
why it matters and leave the otherwise perfectly readable and
understandable code alone.
Thanks,
tglx
Powered by blists - more mailing lists