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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96b6702a-8e3d-0ff9-2a86-75120bac189e@gentwo.org>
Date: Thu, 3 Jul 2025 07:51:02 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Thomas Gleixner <tglx@...utronix.de>
cc: Christoph Lameter via B4 Relay <devnull+cl.gentwo.org@...nel.org>, 
    Anna-Maria Behnsen <anna-maria@...utronix.de>, 
    Frederic Weisbecker <frederic@...nel.org>, Ingo Molnar <mingo@...nel.org>, 
    linux-kernel@...r.kernel.org, linux-mm@...ck.org, sh@...two.org, 
    Darren Hart <dvhart@...radead.org>, Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] Skew tick for systems with a large number of
 processors

On Thu, 3 Jul 2025, Thomas Gleixner wrote:

> >> So while you preserved the behaviour of the command line option in the
> >> most obscure way, you did not even make an attempt to explain why this
> >> change does not bring back the issues which caused the removal in commit
> >> af5ab277ded0 or why they are irrelevant today.
> >
> > As pointed out in the patch description: The synchronized tick (aside from
> > the jitter) also causes power spikes on large core systems which can cause
> > system instabilities.
>
> That's a _NEW_ problem and has nothing to do with the power saving
> concerns which led to af5ab277ded0.

The contemporary "advanced on chip power savings" really bite in this
scenario. ;-) It was rather suprising to see what can happen.

> It's not rocket science to validate whether these power saving concerns
> still apply and to reach out to people who have been involved in this
> and ask them to revalidate. I just Cc'ed Arjan for you.

They definitely apply on an Android phone with fewer cores. There you
would want to reduce the number of wakeups as much as possible to
conserver power so it needs synchronized mode.

That is why my initial thought was to make it dependent on the number of
active processors.

> There is only a limited range of scenarios, which need to be looked at:
>
>       - Big servers and the power saving issues on lightly loaded
>         machines

If it is only a few active cores and the system is basically idle then
it is better to have a synchronized tick but if the system has lots of
active processors then the tick should be skewed. So maybe one idea
would be to have a counter of active ticks and skew them if that number
gets too high.

>       - Battery operated devices

These usually have 1-4 cores. So synchronized is obviously the best.

>       - Virtualization (guests)

I think there is work to do here to sync the ticks between host and guest
for further power savings.

> That might not cover 100% of the use cases, but should be a good enough
> coverage to base an informed decision on.

Yea lets see what others say on the matter.




> If we could have predicted the future and the consequences of ad hoc
> decisions, we wouldn't have had a BKL, which took only 20 years of
> effort to get rid of (except for the well hidden leftovers in tty).

Oh the BKL was good. Synchronization was much faster after all and less
complex. I am sure a BKL approach on small systems would still improve
performance.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ