From: Ulf Hansson <ulf.hansson@linaro.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: "open list:THERMAL" <linux-pm@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Thara Gopinath <thara.gopinath@linaro.org>,
jani.nikula@linux.intel.com,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
rodrigo.vivi@intel.com, David Airlie <airlied@linux.ie>,
"Intel graphics driver community testing & development"
<intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time
Date: Thu, 20 Dec 2018 09:15:27 +0100 [thread overview]
Message-ID: <CAPDyKFocLDoJG5P3ywAV7+p6PL3fnno1cZ87=-Mzn49ag-y6tw@mail.gmail.com> (raw)
In-Reply-To: <CAKfTPtBp+eCqyCWh27FWe8pkrFJiLQitPL_+kfL42r_BTq6DcQ@mail.gmail.com>
On Wed, 19 Dec 2018 at 17:52, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Wed, 19 Dec 2018 at 17:36, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> > <vincent.guittot@linaro.org> wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > > > <vincent.guittot@linaro.org> wrote:
> > > > >
> > > > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > > >
> > >
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > > > > > > > > index 7062469..6461469 100644
> > > > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct device *dev, enum rpm_status status)
> > > > > > > > > dev->power.runtime_status = status;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status status, bool update)
> > > > > > > > > +{
> > > > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > > > >
> > > > > > > > I think you should stay on jiffies here - and then switch to ktime in patch 3.
> > > > > > > >
> > > > > > > > > + u64 delta = 0, time = 0;
> > > > > > > > > + unsigned long flags;
> > > > > > > > > +
> > > > > > > > > + spin_lock_irqsave(&dev->power.lock, flags);
> > > > > > > > > +
> > > > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > > > + goto unlock;
> > > > > > > > > +
> > > > > > > > > + /* Add ongoing state if requested */
> > > > > > > > > + if (update && dev->power.runtime_status == status)
> > > > > > > > > + delta = now - dev->power.accounting_timestamp;
> > > > > > > > > +
> > > > > > > >
> > > > > > > > Hmm. Do we really need to update the accounting timestamp? I would
> > > > > > > > rather avoid it if possible.
> > > > > > >
> > > > > > > i915/drm uses this to track ongoing suspended state. In fact they are
> > > > > > > mainly interested by this part
> > > > > >
> > > > > > Again, sorry I don't follow.
> > > > >
> > > > > In fact we don't update dev->power.accounting_timestamp but only use
> > > > > it to get how much time has elapsed in the current state.
> > > > >
> > > > > >
> > > > > > My suggested changes below, would do exactly that; track the ongoing
> > > > > > suspended state.
> > > > > >
> > > > > > The user can call the function several times while the device remains
> > > > > > RPM_SUSPENDED, and if needed the user could then compute the delta
> > > > > > in-between the calls, for whatever reason that may be needed.
> > > > >
> > > > > So I'm not sure to catch your question:
> > > > > Is your problem linked to status != RPM_SUSPENDED or the update
> > > > > parameter that compute delta ?
> > > >
> > > > My intent was to keep things simple.
> > > >
> > > > 1. Only expose last suspended time, which means tracking the ongoing
> > > > suspended state. In other words, you can also remove "enum rpm_status
> > > > status" as the in-parameter to pm_runtime_accounted_time_get().
> > >
> > > Ok for this point if Rafael doesn't see any benefit of keeping the
> > > generic interface
> > >
> > > > 2. Don't allow the user of pm_runtime_accounted_time_get() to update
> > > > the current timestamp, in "dev->power.accounting_timestamp".
> > >
> > > But pm_runtime_accounted_time_get doesn't update
> > > dev->power.accounting_timestamp, it only reads it to know when when
> > > the last state transition happened
> >
> > I understand, sorry for not being clear enough.
> >
> > My point is, you must not update dev->power.suspended_time, without
> > also setting a new value for dev->power.accounting_timestamp.
> > Otherwise, the next time the core calls
> > update_pm_runtime_accounting(), it will end up adding a wrong delta to
> > dev->power.suspended_time.
>
> I fully agree on that and that's why dev->power.accounting_timestamp
> is not and has never been modified
Huh, I have miss-read your patch. What a mess, my apologies.
>
> >
> > BTW, it seems like you have based this on top of some patch converting
> > from jiffies to ktime, as I can't fine dev->power.suspended_time, but
> > instead I have dev->power.suspended_jiffies.
> >
> > On Wed, 19 Dec 2018 at 14:26, Vincent Guittot
> > <vincent.guittot@linaro.org> wrote:
> > >
> > > On Wed, 19 Dec 2018 at 11:43, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > On Wed, 19 Dec 2018 at 11:34, Vincent Guittot
> > > > <vincent.guittot@linaro.org> wrote:
> > > > >
> > > > > On Wed, 19 Dec 2018 at 11:21, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > > >
> > >
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > > > > > > > > index 7062469..6461469 100644
> > > > > > > > > --- a/drivers/base/power/runtime.c
> > > > > > > > > +++ b/drivers/base/power/runtime.c
> > > > > > > > > @@ -88,6 +88,32 @@ static void __update_runtime_status(struct device *dev, enum rpm_status status)
> > > > > > > > > dev->power.runtime_status = status;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > +u64 pm_runtime_accounted_time_get(struct device *dev, enum rpm_status status, bool update)
> > > > > > > > > +{
> > > > > > > > > + u64 now = ktime_to_ns(ktime_get());
> > > > > > > >
> > > > > > > > I think you should stay on jiffies here - and then switch to ktime in patch 3.
> > > > > > > >
> > > > > > > > > + u64 delta = 0, time = 0;
> > > > > > > > > + unsigned long flags;
> > > > > > > > > +
> > > > > > > > > + spin_lock_irqsave(&dev->power.lock, flags);
> > > > > > > > > +
> > > > > > > > > + if (dev->power.disable_depth > 0)
> > > > > > > > > + goto unlock;
> > > > > > > > > +
> > > > > > > > > + /* Add ongoing state if requested */
> > > > > > > > > + if (update && dev->power.runtime_status == status)
> > > > > > > > > + delta = now - dev->power.accounting_timestamp;
> > > > > > > > > +
> > > > > > > >
> > > > > > > > Hmm. Do we really need to update the accounting timestamp? I would
> > > > > > > > rather avoid it if possible.
> > > > > > >
> > > > > > > i915/drm uses this to track ongoing suspended state. In fact they are
> > > > > > > mainly interested by this part
> > > > > >
> > > > > > Again, sorry I don't follow.
> > > > >
> > > > > In fact we don't update dev->power.accounting_timestamp but only use
> > > > > it to get how much time has elapsed in the current state.
> > > > >
> > > > > >
> > > > > > My suggested changes below, would do exactly that; track the ongoing
> > > > > > suspended state.
> > > > > >
> > > > > > The user can call the function several times while the device remains
> > > > > > RPM_SUSPENDED, and if needed the user could then compute the delta
> > > > > > in-between the calls, for whatever reason that may be needed.
> > > > >
> > > > > So I'm not sure to catch your question:
> > > > > Is your problem linked to status != RPM_SUSPENDED or the update
> > > > > parameter that compute delta ?
> > > >
> > > > My intent was to keep things simple.
> > > >
> > > > 1. Only expose last suspended time, which means tracking the ongoing
> > > > suspended state. In other words, you can also remove "enum rpm_status
> > > > status" as the in-parameter to pm_runtime_accounted_time_get().
> > >
> > > Ok for this point if Rafael doesn't see any benefit of keeping the
> > > generic interface
> > >
> > > > 2. Don't allow the user of pm_runtime_accounted_time_get() to update
> > > > the current timestamp, in "dev->power.accounting_timestamp".
> > >
> > > But pm_runtime_accounted_time_get doesn't update
> > > dev->power.accounting_timestamp, it only reads it to know when when
> > > the last state transition happened
> > >
> > > >
> > > > Is that okay for the drm driver, to do what it does today?
> > >
> > > drm driver needs 2 things: the accounted suspended time since the
> > > last transition
> >
> > The core keeps tracks of the "total suspended time". Each time
> > update_pm_runtime_accounting() is called, and the state is
> > RPM_SUSPENDED it adds a delta to the total suspended time. Just to be
> > clear, this may even happen when userspace reads the
> > "runtime_suspended_time" sysfs node.
> >
> > My point is, the core doesn't track the "total suspended time since
> > the last transition", which seems to be what the drm driver tries to
> > figure out.
> >
> > Just to be clear, I don't think we should update the core to provide
> > the data reflecting that time, as it would add overhead from
> > additional time computations. I think it's better to push this down to
>
> Which kind of overhead are you referring ? This is done only when
> pm_runtime_accounted_time_get') is called and doesn't modify
> pm core metrics
I was talking hypothetically.
Having a function that performs some computation when actually called
by the user, along the lines of what you propose in $subject patch, is
in principle fine by me.
The important part, is that we don't make core to perform *additional*
unnecessary time computations, each time it calls
update_pm_runtime_accounting().
>
> > those drivers that needs it, as it seems like a highly unusual thing.
> >
> > Instead, perhaps we should provide an API
> > (pm_runtime_suspended_time()) that simply returns the value of
> > dev->power.suspended_jiffies. The driver/subsystem could then call
> > this API from its ->runtime_suspend|resume() callbacks, for example,
> > to store values from it locally and later compute the deltas from it
> > that it needs.
>
> not sure that i915/drm has such call back
>
> >
> > Do note that, the core updates the status of the device to
> > RPM_SUSPENDED, after the ->runtime_suspend() callback has returned a
> > successful error code. Hence, calling the API from a
> > ->runtime_suspend() callback would fetch the total suspended time, up
> > until the last time the device became runtime resumed. That should be
> > helpful, right?
>
> TBH, I don't know if this would help or not. i915/drm driver developer
> should have the answer
>
> AFAICT, all this code is not driver in itself but some perf monitoring
> stuff that estimate a events when it is not accessible anymore because
> devices is suspended
> >
> > > and the time elapse in the current state when suspened
> >
> > Re-thinking this a bit from my earlier comments - and by following the
> > above reasoning, it sounds like this better belongs in the
> > driver/subsystem, without requiring any data from the core.
> >
> > The driver/subsystem could just store a timestamp in it's
> > ->runtime_suspend() callback and whenever needed, it could compute a
> > delta towards it. That should work, right?
>
> I don't know i915/drm enough to know all that details
Okay, so let me re-summarize the main issue I see with your approach
in $subject patch.
dev->power.accounting_timestamp can't be used to know when last
transition was made. If I understand correctly, that is how you use
it. No?
Anyway, as stated, that's because the timestamp becomes updated, if
update_pm_runtime_accounting() is called via the sysfs nobs, which
means there is no state transition happening, but only accounting data
is updated.
So, what I think we can do from the core perspective, if it helps
(which I am not sure of):
1. Export a function, which returns the value of dev->power.suspended_jiffies.
2. Export a wrapper function (to deal with locking) which calls
update_pm_runtime_accounting(). This wrapper function allows the user
the update the total suspended time, also taking into account the time
spent in the current state.
Other than that, I think the rest should be managed in the drm driver itself.
Kind regards
Uffe
next prev parent reply other threads:[~2018-12-20 8:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 14:55 [PATCH v3 0/3] Move pm_runtime accounted time to raw nsec Vincent Guittot
2018-12-18 14:55 ` [RFC v3 1/3] PM/runtime: Add a new interface to get accounted time Vincent Guittot
2018-12-19 9:58 ` Ulf Hansson
2018-12-19 10:11 ` Vincent Guittot
2018-12-19 10:20 ` Ulf Hansson
2018-12-19 10:34 ` Vincent Guittot
2018-12-19 10:43 ` Ulf Hansson
2018-12-19 10:52 ` Ulf Hansson
2018-12-19 11:13 ` Ulf Hansson
2018-12-19 13:25 ` Vincent Guittot
2018-12-19 16:36 ` Ulf Hansson
2018-12-19 16:52 ` Vincent Guittot
2018-12-20 8:15 ` Ulf Hansson [this message]
2018-12-20 8:44 ` Vincent Guittot
2018-12-20 9:40 ` Ulf Hansson
2018-12-19 15:25 ` Vincent Guittot
2018-12-18 14:55 ` [RFC 2/3] drm/i915: Move on the new pm runtime interface Vincent Guittot
2018-12-18 14:55 ` [PATCH 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting Vincent Guittot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPDyKFocLDoJG5P3ywAV7+p6PL3fnno1cZ87=-Mzn49ag-y6tw@mail.gmail.com' \
--to=ulf.hansson@linaro.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rodrigo.vivi@intel.com \
--cc=thara.gopinath@linaro.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).