linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Sibi Sankar <sibis@codeaurora.org>,
	Android Kernel Team <kernel-team@android.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/5] OPP: Improve require-opps linking
Date: Thu, 25 Jul 2019 18:52:13 -0700	[thread overview]
Message-ID: <CAGETcx9yO7HCz-rvqRMQf6srN_9-O_wc1bb7HadL+4QxvuqyWA@mail.gmail.com> (raw)
In-Reply-To: <20190725051742.mn54pi722txkpddg@vireshk-i7>

On Wed, Jul 24, 2019 at 10:17 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 24-07-19, 21:09, Saravana Kannan wrote:
> > On Wed, Jul 24, 2019 at 8:07 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > We should be doing this whenever a new OPP table is created, and see
> > > if someone else was waiting for this OPP table to come alive.
> >
> > Searching the global OPP table list seems a ton more wasteful than
> > doing the lazy linking. I'd rather not do this.
>
> We can see how best to optimize that, but it will be done only once
> while a new OPP table is created and putting stress there is the right
> thing to do IMO. And doing anything like that in a place like
> opp-set-rate is the worst one. It will be a bad choice by design if
> you ask me and so I am very much against that.
>
> > > Also we
> > > must make sure that we do this linking only if the new OPP table has
> > > its own required-opps links fixed, otherwise delay further.
> >
> > This can be done. Although even without doing that, this patch is
> > making things better by not failing silently like it does today? Can I
> > do this later as a separate patch set series?
>
> I would like this to get fixed now in a proper way, there is no hurry
> for a quick fix currently. No band-aids please.
>
> > > Even then I don't want to add these checks to those places. For the
> > > opp-set-rate routine, add another flag to the OPP table which
> > > indicates if we are ready to do dvfs or not and mark it true only
> > > after the required-opps are all set.
> >
> > Honestly, this seems like extra memory and micro optimization without
> > any data to back it.
>
> Again, opp-set-rate isn't supposed to do something like this. It
> shouldn't handle initializations of things, that is broken design.
>
> > Show me data that checking all these table
> > pointers is noticeably slower than what I'm doing. What's the max
> > "required tables count" you've seen in upstream so far?
>
> Running anything extra (specially some initialization stuff) in
> opp-set-rate is wrong as per me and as a Maintainer of the OPP core it
> is my responsibility to not allow such things to happen.

Doing operations lazily right before they are needed isn't something
new in the kernel. It's done all over the place (VFP save/restore?).
It's not worth arguing though -- so I'll agree to disagree but follow
the Maintainer's preference.

> > I'd even argue that doing it the way I do might actually reduce the
> > cache misses/warm the cache because those pointers are going to be
> > searched/used right after anyway.
>
> So you want to make the cache hot with data, by running some code at a
> place where it is not required to be run really, and the fact that
> most of the data cached may not get used anyway ? And that is an
> improvement somehow ?

My point is that both of us are hypothesizing and for some
micro-optimization like this, data is needed.

-Saravana

  reply	other threads:[~2019-07-26  1:52 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 22:23 [PATCH v3 0/5] Add required-opps support to devfreq passive gov Saravana Kannan
2019-07-17 22:23 ` [PATCH v3 1/5] OPP: Allow required-opps even if the device doesn't have power-domains Saravana Kannan
2019-07-17 22:23 ` [PATCH v3 2/5] OPP: Add function to look up required OPP's for a given OPP Saravana Kannan
2019-07-23  9:53   ` Viresh Kumar
2019-07-24  0:23     ` Saravana Kannan
2019-07-25  2:58       ` Viresh Kumar
2019-07-25  3:46         ` Saravana Kannan
2019-07-25  5:38           ` Viresh Kumar
2019-07-26  1:41             ` Saravana Kannan
2019-07-17 22:23 ` [PATCH v3 3/5] OPP: Improve require-opps linking Saravana Kannan
2019-07-23 10:28   ` Viresh Kumar
2019-07-23 20:36     ` Saravana Kannan
     [not found]     ` <CAGETcx-6M9Ts8tfMf6aA8GjMyzK5sOLr069ZCxTG7RHMFPLzHw@mail.gmail.com>
2019-07-25  3:07       ` Viresh Kumar
2019-07-25  4:09         ` Saravana Kannan
2019-07-25  5:17           ` Viresh Kumar
2019-07-26  1:52             ` Saravana Kannan [this message]
2019-07-26 21:23               ` Saravana Kannan
2019-07-29  7:26                 ` Viresh Kumar
2019-07-30 23:02   ` Hsin-Yi Wang
2019-07-30 23:05     ` Saravana Kannan
2019-11-25 11:28   ` Viresh Kumar
2019-11-25 11:29     ` Viresh Kumar
2019-12-05 19:11       ` Saravana Kannan
2019-12-10  5:21         ` Viresh Kumar
2020-01-27  6:11     ` Viresh Kumar
2020-01-29 13:34       ` Sibi Sankar
2020-01-30  4:21         ` Viresh Kumar
2021-01-18  7:21           ` Hsin-Yi Wang
2021-01-18  7:34             ` Viresh Kumar
2021-01-18  7:39               ` Hsin-Yi Wang
2021-01-20  0:05                 ` Saravana Kannan
2021-01-27 11:54                 ` Viresh Kumar
2021-01-27 14:40                   ` Hsin-Yi Wang
2021-01-28  4:13                     ` Viresh Kumar
2021-01-28  5:05                       ` Hsin-Yi Wang
2019-07-17 22:23 ` [PATCH v3 4/5] PM / devfreq: Cache OPP table reference in devfreq Saravana Kannan
2019-07-17 22:23 ` [PATCH v3 5/5] PM / devfreq: Add required OPPs support to passive governor Saravana Kannan
2019-07-23 10:04   ` Viresh Kumar
2019-07-24  0:26     ` Saravana Kannan
2019-07-25  3:01       ` Viresh Kumar
2019-07-25  3:58         ` Saravana Kannan

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=CAGETcx9yO7HCz-rvqRMQf6srN_9-O_wc1bb7HadL+4QxvuqyWA@mail.gmail.com \
    --to=saravanak@google.com \
    --cc=cw00.choi@samsung.com \
    --cc=kernel-team@android.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=sboyd@kernel.org \
    --cc=sibis@codeaurora.org \
    --cc=viresh.kumar@linaro.org \
    --cc=vireshk@kernel.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).