[Intel-gfx] [PATCH v4 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting

Vincent Guittot vincent.guittot at linaro.org
Fri Dec 21 10:06:53 UTC 2018


Hi Rafael,

On Fri, 21 Dec 2018 at 09:58, Rafael J. Wysocki <rafael at kernel.org> wrote:
>
> On Thu, Dec 20, 2018 at 11:03 PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
> >
> > On Thu, 20 Dec 2018 at 15:17, Vincent Guittot
> > <vincent.guittot at linaro.org> wrote:
> > >
> > > From: Thara Gopinath <thara.gopinath at linaro.org>
> > >
> > > This patch replaces jiffies based accounting for runtime_active_time
> > > and runtime_suspended_time with ktime base accounting. This makes the
> > > runtime debug counters inline with genpd and other pm subsytems which
> > > uses ktime based accounting.
> > >
> > > Signed-off-by: Thara Gopinath <thara.gopinath at linaro.org>
> > > [move from ktime to raw nsec]
> > > Signed-off-by: Vincent Guittot <vincent.guittot at linaro.org>
> > > ---
> > >  drivers/base/power/runtime.c | 17 +++++++++--------
> > >  drivers/base/power/sysfs.c   | 11 ++++++++---
> > >  include/linux/pm.h           |  6 +++---
> > >  3 files changed, 20 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > > index e695544..f700524 100644
> > > --- a/drivers/base/power/runtime.c
> > > +++ b/drivers/base/power/runtime.c
> > > @@ -64,8 +64,8 @@ static int rpm_suspend(struct device *dev, int rpmflags);
> > >   */
> > >  void update_pm_runtime_accounting(struct device *dev)
> > >  {
> > > -       unsigned long now = jiffies;
> > > -       unsigned long delta;
> > > +       u64 now = ktime_to_ns(ktime_get());
> > > +       u64 delta;
> > >
> > >         delta = now - dev->power.accounting_timestamp;
> > >
> > > @@ -75,9 +75,9 @@ void update_pm_runtime_accounting(struct device *dev)
> > >                 return;
> > >
> > >         if (dev->power.runtime_status == RPM_SUSPENDED)
> > > -               dev->power.suspended_jiffies += delta;
> > > +               dev->power.suspended_time += delta;
> > >         else
> > > -               dev->power.active_jiffies += delta;
> > > +               dev->power.active_time += delta;
> > >  }
> > >
> > >  static void __update_runtime_status(struct device *dev, enum rpm_status status)
> > > @@ -88,17 +88,18 @@ static void __update_runtime_status(struct device *dev, enum rpm_status status)
> > >
> > >  u64 pm_runtime_suspended_time(struct device *dev)
> > >  {
> > > -       unsigned long flags, time;
> > > +       u64 time;
> > > +       unsigned long flags;
> > >
> > >         spin_lock_irqsave(&dev->power.lock, flags);
> > >
> > >         update_pm_runtime_accounting(dev);
> > >
> > > -       time = dev->power.suspended_jiffies;
> > > +       time = dev->power.suspended_time;
> > >
> > >         spin_unlock_irqrestore(&dev->power.lock, flags);
> > >
> > > -       return jiffies_to_nsecs(time);
> > > +       return time;
> > >  }
> > >  EXPORT_SYMBOL_GPL(pm_runtime_suspended_time);
> > >
> > > @@ -1503,7 +1504,7 @@ void pm_runtime_init(struct device *dev)
> > >         dev->power.request_pending = false;
> > >         dev->power.request = RPM_REQ_NONE;
> > >         dev->power.deferred_resume = false;
> > > -       dev->power.accounting_timestamp = jiffies;
> > > +       dev->power.accounting_timestamp = ktime_to_ns(ktime_get());
> >
> > This change worries me a bit, but it may not be a problem in practice.
> >
> > pm_runtime_init() is called when devices get initialized, via
> > device_initialize(). If timekeeping has not been initialized prior a
> > call to ktime_get() is done, it will fail and causing a NULL pointer
> > deference or something along those lines.
> >
> > In other words, do we know that device_initialize() is always called
> > after timekeeping has been initialized during boot?
>
> We do.
>
> timekeeping_init() is called early in start_kernel() which is way
> before driver_init() (and that's when devices can start to be
> initialized) called from rest_init() via kernel_init_freeable() and
> do_basic_setup().

Thanks for the confirmation. I'm going to add your answer in the
commit message so we will have the answer next time someone will
wonder


More information about the Intel-gfx mailing list