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 8271A13A244 for ; Tue, 27 Jan 2026 08:37:59 +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=1769503079; cv=none; b=i3pxgYDs/eqGH4TjfcoBZ24L+IMELWaCGREB+zAETjuQJExw9gZiVeBFg3IBsskvTpKeA2ZTjor2J2/2T/Ae59mP3eXNiKECkEufAzcdc/vvpE9X4Ia89Y1Tq7lGFm2uJb7SebK2FeLGpoL5iby1AZOttC955amaWrIwcrayBHU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769503079; c=relaxed/simple; bh=XbBwm1hHNjznWk6XelLpcySifAPkhJRgBuTjt55Rd+8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=pFETb3zDAeZebZIf66W3r4OU19hLP5mVPzRs/G4Mo9ohS9Rj95EnS0vFTAA6WqqNIiJNgeWw4NRXKpl1c+YzEH01vQ0UhC7VOECsJewSeeKwE4o4ZYbd5OyJtQQHdDnzTqO1lBskoDUHR75Pv2yJpXeE7wgDlGOYz6byCaYENZg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TtrCsFkC; 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="TtrCsFkC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC6F6C116C6; Tue, 27 Jan 2026 08:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769503079; bh=XbBwm1hHNjznWk6XelLpcySifAPkhJRgBuTjt55Rd+8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TtrCsFkCwOXK+4fyeCAC0ei+xPXjeHpj1xZI9/oXOF+2RFxfs4zczM+hlvvu8+m+e dkWNL3x8U/CRDhHHqVkMVSl4fB8gip1VDokmfi0NGHbvNpoMQzSZzFl63daPa3Cq0J UYcwNgDWqJvwLVOc2/VjhNMvuyWaaaoCx2Tp7LrithxyLiKdNuSk9YXByrPDMUFPLN q1SAC/+BQEJOc1eWmC0+M2VM03ZG354tMle1+/082FAyf44EX04eSK8YaJPNQE+Gka EbgYvkHUdtadlYJH6gTWTGEUQJHHVtIKuyrbnjVvkL0BJnUF7ltNQ1stbHRCqXguBp wKFn6wtI4mVLQ== From: Thomas Gleixner To: Zhan Xusheng Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, zhanxusheng1024@gmail.com, zhanxusheng@xiaomi.com Subject: Re: [PATCH v2] genirq/matrix: Clarify CPU selection logic In-Reply-To: <20260127024134.6872-1-zhanxusheng@xiaomi.com> References: <20260127024134.6872-1-zhanxusheng@xiaomi.com> Date: Tue, 27 Jan 2026 09:37:55 +0100 Message-ID: <87wm13bgd8.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 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