[<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