[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0jNf+of+XpRP8F0yvYyW20yHNs9NS02biuH5T0b6PcP3w@mail.gmail.com>
Date: Mon, 10 Sep 2018 23:40:43 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: kw@...ahl.im
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Linux PM <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] cpuidle: enter_state: Don't needlessly calculate diff time
On Mon, Sep 10, 2018 at 11:24 PM Fieah Lim <kw@...ahl.im> wrote:
>
> On Tue, Sep 11, 2018 at 4:17 AM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> > On Mon, Sep 10, 2018 at 7:40 PM Fieah Lim <kw@...ahl.im> wrote:
> >>
> >> Currently we use ktime_us_delta() to calculate last residency and
> >> state usage unconditionally, it makes no sense to do this calculation
> >> when we fails to enter any idle state.
> >> It can be optimize by moving the calculation after entered_state >= 0
> >>
> >> While at it, merge those comment blocks into one and remove a
> >> space between type casting of diff.
> >>
> >> This patch has no functional changes.
> >>
> >> Signed-off-by: Fieah Lim <kw@...ahl.im>
> >> ---
> >> Changes from v1:
> >> - Rewrite changelog as Rafael J. Wysocki suggested
> >> ---
> >> drivers/cpuidle/cpuidle.c | 17 ++++++++---------
> >> 1 file changed, 8 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> >> index 6df894d65d9e..5f6b2c9b6555 100644
> >> --- a/drivers/cpuidle/cpuidle.c
> >> +++ b/drivers/cpuidle/cpuidle.c
> >> @@ -247,21 +247,20 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
> >> if (!cpuidle_state_is_coupled(drv, index))
> >> local_irq_enable();
> >>
> >> - diff = ktime_us_delta(time_end, time_start);
> >> - if (diff > INT_MAX)
> >> - diff = INT_MAX;
> >> -
> >> - dev->last_residency = (int) diff;
> >> + dev->last_residency = 0;
> >
> > You don't need this line if you retain the "else" branch below, do you?
> >
> You are right, should I make a v3?
Yes, please.
Powered by blists - more mailing lists