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 9F73533AD87 for ; Fri, 6 Feb 2026 13:37:41 +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=1770385061; cv=none; b=ipYx/j+QRSQSE5vef6eNKMHX14YP+/udDMomYFvWAxpc4Zy3khSotj+VvVUCDGrp0mDsH3oSKLCanTzcrKQwEdDWVVThknnmozXiu08VUJLI1s1erRfoYfYmiZLYr0UGQs73lXARL3qv/nQYplxgRtU0/zJ+krDbY3/vEQ/a+Mw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770385061; c=relaxed/simple; bh=dWv+5gciHZ9dPOYOGuk6feAYiCMXYhPLHoW4zPsNEN4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=APjV7Rl/TstxbyHqPvYPQvE2RuwYuEhtC4phb/Xg3ikNUV/jJj9AMxHnJUjaqjbgbCxNnuH3rukIrn31csYfrSvM/5ceB2LDlQV6LFIfZhM98hNWICYD2ruWMcCk+8eUhJfbawrao/5lcrmocPSa1YTV3y8Wj94CXCZk/kaf3Ao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YXN2qTYF; 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="YXN2qTYF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA5A2C116C6; Fri, 6 Feb 2026 13:37:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770385061; bh=dWv+5gciHZ9dPOYOGuk6feAYiCMXYhPLHoW4zPsNEN4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YXN2qTYFEUojdxJRmD4nimL2sJ6Z/FgIF9bOtpYsAOdo2nrFAhuio6LRSKQuIWUO8 QEm8+8FOETlBpD2S59StlUeqjMfE5wAdu+TvEINvIqZuvIjvzjnieltsQ4u/QS3h+o L2pAr/9IZ9ZuQWoI78AlNpPDZx1r7yPp6oXxM1GrY9X4Pp0AYgBE3XKOD2Vp1HERiS a4FK3ugo9lT1rfU1E5L9Tck6iYI7U9ysYmlWNJPz1/3bzA4NBb56nqW1E/3hEyVfer YHUDZbdVGOH4BpwFas9Mgg50E60QbdWjJmTup4PIZVjsFickBoxpPpnpnSFrZDSidh fdYr387V/N28A== From: Thomas Gleixner To: =?utf-8?B?6L+e5a2Q5ra1?= <17317795071@163.com>, mingo@kernel.org, frederic@kernel.org Cc: linux-kernel@vger.kernel.org Subject: Re: [Question] Voltage droop from synchronized timer interrupts(tick) on many-core SoCs leads to system instability In-Reply-To: <775bc4a3.3968.19c2c24a1e5.Coremail.17317795071@163.com> References: <775bc4a3.3968.19c2c24a1e5.Coremail.17317795071@163.com> Date: Fri, 06 Feb 2026 14:37:37 +0100 Message-ID: <87y0l6yov2.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 05 2026 at 12:52, =E8=BF=9E=E5=AD=90=E6=B6=B5 wrote: > Given this constraint, we would greatly appreciate your insights on the f= ollowing technical questions:=20 Who is 'we'? You are hiding behind an anonymized email address and completely fail to provide details about your secret sauce SoC. > 1. Why does the timer interrupt path consume so much power and exhibit > such large instantaneous variations? Our power simulation shows that > the average power during timer interrupt handling is comparable to > Dhrystone benchmark. Is that a serious question? How should we know what makes your SoC design sensitive to it? You have the tools which observe the problem, so you should be able to pin point what the actual issue is, no? > 3. Beyond skew_tick=3D1, are there other kernel mechanisms or runtime > strategies that could reduce the power impact of synchronized timer > events? Are there plans in future kernel versions to address this > issue more fundamentally=E2=80=94especially for many-core platforms? Again. How should we address a problem which is only described by hand-waving? You completely fail to provide context and circumstances. Provide a proper analysis that explains what the actual root cause is and then we can debate whether that's solvable in software or not. Just crying 'timer interrupt' is not even close to an analysis. If there is a systematic problem somewhere then we are happy to look for a solution, but without analysis and data we are not doing anything. Just for the record: The Voltage droop issue is known for more a decade and there have been solutions published way before your SoC was designed. Aside of your (whatever it is) and some odd Ampere SoC none of the contemporary multi-core designs even with hundreds of cores suffer from this. Seems there are hardware architects out there who pay attention to research. Thanks, tglx