lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o7bhmbgk.ffs@tglx>
Date: Thu, 14 Mar 2024 10:03:55 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>, Florian Fainelli
 <f.fainelli@...il.com>
Cc: Joel Fernandes <joel@...lfernandes.org>, Boqun Feng
 <boqun.feng@...il.com>, Anna-Maria Behnsen <anna-maria@...utronix.de>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-kernel@...r.kernel.org, kernel-team@...a.com, paulmck@...nel.org,
 mingo@...nel.org, rcu@...r.kernel.org, neeraj.upadhyay@....com,
 urezki@...il.com, qiang.zhang1211@...il.com, frederic@...nel.org,
 bigeasy@...utronix.de, chenzhongjin@...wei.com, yangjihong1@...wei.com,
 rostedt@...dmis.org, Justin Chen <justin.chen@...adcom.com>
Subject: Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes
 for v6.9]

On Wed, Mar 13 2024 at 21:59, Russell King (Oracle) wrote:
> On Wed, Mar 13, 2024 at 02:30:43PM -0700, Florian Fainelli wrote:
> I haven't understood the code there yet, and how it would interact with
> arch code, but one thing that immediately jumps out to me is this:
>
> "    As long as a CPU is busy it expires both local and global timers. When a
>     CPU goes idle it arms for the first expiring local timer."
>
> So are local timers "armed" when they are enqueued while the cpu is
> "busy" during initialisation, and will they expire, and will that
> expiry be delivered in a timely manner?

The local timers are timers which are pinned on a CPU. Global ones do
not care about the CPU they expire on.

So if the CPU goes idle then it arms for the first local timer. If the
first global timer expires after the first local, nothing to see. If it
expires before then that timer is queued in the migration hierarchy and
some other busy CPU will take care of it. If the last CPU goes idle then
it has to arm for the first timer (it's own local, global and the
hierarchy). So it's all covered in theory, but there seems to be an
issue somewhere. We'll figure it out.

Thanks,

        tglx



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ