[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMD8fP36By1KYgkk@localhost.localdomain>
Date: Wed, 26 Jul 2023 12:59:08 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Anna-Maria Behnsen <anna-maria@...utronix.de>,
Vincent Guittot <vincent.guittot@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
"Gautham R. Shenoy" <gautham.shenoy@....com>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Valentin Schneider <vschneid@...hat.com>
Subject: Re: Stopping the tick on a fully loaded system
Le Tue, Jul 25, 2023 at 04:27:56PM +0200, Rafael J. Wysocki a écrit :
> On Tue, Jul 25, 2023 at 3:07 PM Anna-Maria Behnsen
> I'll let Frederic respond to the above, but from my perspective it all
> just means that the idle governors in use today are not perfect.
>
> However, they will never be perfect, because they only have a little
> time to make a decision, so it's a matter of balancing that with
> precision.
So, even without considering Anna-Maria's patchset, sparing
the next timer lookup if we already know we won't stop it would show
quite a benefit because that lookup involves locking and quite some
overhead walking through all levels.
Thanks.
Powered by blists - more mailing lists