[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f3nt5ve3derp2kmbe5zcj3kvtozcrhsvbduxtn5yj5yqnfvztb@v2nm4zuvyzhq>
Date: Wed, 12 Jul 2023 03:48:22 +0900
From: Kazuki Hashimoto <kazukih0205@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
Hector Martin <marcan@...can.st>,
Kazuki Hashimoto <kazukih0205@...il.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"Rafael J. Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] cpuidle: Don't pass any values to
cpuidle_not_available
on oue, Jul 11, 2023 at 09:42:31AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 11, 2023 at 02:54:21PM +0900, Kazuki Hashimoto wrote:
> > There's no reason to pass any values to cpuidle_not_available() as the
> > function works standalone. Since we're planning to use the function in
> > other places, make it so to avoid code duplication.
> >
> > Signed-off-by: Kazuki Hashimoto <kazukih0205@...il.com>
> > ---
> > drivers/cpuidle/cpuidle.c | 6 ++++--
> > include/linux/cpuidle.h | 6 ++----
> > kernel/sched/idle.c | 2 +-
> > 3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > index 737a026ef58a..c9ba51e0fa38 100644
> > --- a/drivers/cpuidle/cpuidle.c
> > +++ b/drivers/cpuidle/cpuidle.c
> > @@ -49,9 +49,11 @@ void disable_cpuidle(void)
> > off = 1;
> > }
> >
> > -bool cpuidle_not_available(struct cpuidle_driver *drv,
> > - struct cpuidle_device *dev)
> > +bool cpuidle_not_available(void)
> > {
> > + struct cpuidle_device *dev = cpuidle_get_device();
> > + struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> > +
> > return off || !initialized || !drv || !dev || !dev->enabled;
> > }
>
> It appears to me these are a lot of conditions to check *every* time we
> go idle -- especially since they hardly, if ever, change.
>
> Can't cpuidle track all this in a single global variable, preferably as
> a static_key ?
I don't think so? I'll drop this one though since it adds unnecesary
overhead.
Thanks,
Kazuki
Powered by blists - more mailing lists