From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03BF633F38C for ; Wed, 28 Jan 2026 11:16:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769598999; cv=none; b=QDPgmhdCVfA1IMV8ru3/IAUpFm7JB0Dv0uXxh6lmZA4FHlBVMec0/8fYFynoNrYzRkvfA+oPRmoX593CRMXSK3X1zgAM5MyJws0wkxFTbZBcFX4C8d5jOikvlt3sgNva00nFoOw8dq91+FwMkIkHgqPlmKizx519DkfmqNnMEfo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769598999; c=relaxed/simple; bh=7Ul2R7koVKjkGPVeodotnGB/8LC9UVqm8SB7g6f9Rq0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Zu/SQBQ/1mBcidrPhIORFsgMOVW4A1hHmPTd5aV9idbsq5/DtnuhlOKmv49J9NAWRugpsS2iaC6jGGtyBtwJpJ0ys2A7LStd2Ggzd1TcjH9SjJ3OQounIeQ+n995RwsnZw+yhlSAxniMUCrAInBTwQJDuWZKCYE2E3tT26bacWA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j0rSmxSS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j0rSmxSS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09AB4C4CEF1; Wed, 28 Jan 2026 11:16:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769598998; bh=7Ul2R7koVKjkGPVeodotnGB/8LC9UVqm8SB7g6f9Rq0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=j0rSmxSSUDGqAnnKGSjNSk6xmqub6GrnYubtwgxkQanBhLmqznVoN9X2/wXjcnhct VTUxDlEkKgmrr5Uo9lxDaV7Pjwk0Kqb0chlUSKcL1LWhwRmBSgUvvXX9z57feqs1Qc Yr/qqfagzs+Aw+T/4mWcrgwdGFelWWaDlURcA7pumYSunxP8ByTtsmDkZEdCsnw8r3 eJHwZ28Szk/30C957s1swX1DcfB2tUdFo/iheopR8KZvmjhxmleaJQ9R7OvB8foL9R mjh87LLU2hqr8DXSOKMloeWu8+uIzlWD+7yQ3tYws+ex0xek78C7JnrcNXtj6i6B/V +u/sW+/CaFOug== From: Thomas Gleixner To: Zhan Xusheng Cc: linux-kernel@vger.kernel.org, linux-irq@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH v3 2/2] genirq/matrix: Avoid implicit tie-breaking by CPU iteration order In-Reply-To: <20260128031406.9473-3-zhanxusheng@xiaomi.com> References: <87wm13bgd8.ffs@tglx> <20260128031406.9473-1-zhanxusheng@xiaomi.com> <20260128031406.9473-3-zhanxusheng@xiaomi.com> Date: Wed, 28 Jan 2026 12:16:35 +0100 Message-ID: <87a4xy9ecs.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Jan 28 2026 at 11:14, Zhan Xusheng wrote: > matrix_find_best_cpu_managed() updates best_cpu even when two CPUs > have the same managed_allocated count. As a result, the final > selection implicitly depends on CPU iteration order. And? > Update the comparison to replace the current best CPU only when a > CPU has a strictly smaller managed_allocated value. This removes > the iteration-order-based tie-breaking for equal cases. And replaces it by a different iteration order based decision, no? What are you actually trying to solve here and why does it matter at all? If it solves nothing then what's the point? > This patch intentionally changes the selection behavior. 1) # git grep 'This patch' Documentation/process/ 2) It's already clear from the above that this changes the behaviour, so no point in repeating the obvious. The phrase "No functional change intended" is very different because it tells the reviewer that this is a pure code refactoring. Thanks, tglx