All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Hector Martin <marcan@marcan.st>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Sibi Sankar <sibis@codeaurora.org>,
	Saravana Kannan <saravanak@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Sven Peter <sven@svenpeter.dev>, Marc Zyngier <maz@kernel.org>,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist
Date: Fri, 15 Oct 2021 13:26:35 +0200	[thread overview]
Message-ID: <CAPDyKFpCw1M8bK5T6a+=x-kHaCco88wiRnvUm5Dy90XU360=4A@mail.gmail.com> (raw)
In-Reply-To: <ca820b86-fc12-63b9-ec6b-5823ddd73aba@marcan.st>

On Thu, 14 Oct 2021 at 19:02, Hector Martin <marcan@marcan.st> wrote:
>
> On 14/10/2021 21.55, Ulf Hansson wrote:
> > On Thu, 14 Oct 2021 at 13:43, Hector Martin <marcan@marcan.st> wrote:
> >> I was poking around and noticed the OPP core can already integrate with
> >> interconnect requirements, so perhaps the memory controller can be an
> >> interconnect provider, and the CPU nodes can directly reference it as a
> >> consumer? This seems like a more accurate model of what the hardware
> >> does, and I think I saw some devices doing this already.
> >
> > Yeah, that could work too. And, yes, I agree, it may be a better
> > description of the HW.
> >
> >>
> >> (only problem is I have no idea of the actual bandwidth numbers involved
> >> here... I'll have to run some benchmarks to make sure this isn't just
> >> completely dummy data)
> >>
>
> So... I tried getting bandwidth numbers and failed. It seems these
> registers don't actually affect peak performance in any measurable way.
> I'm also getting almost the same GeekBench scores on macOS with and
> without this mechanism enabled, although there is one subtest that seems
> to show a measurable difference.
>
> My current guess is this is something more subtle (latencies? idle
> timers and such?) than a performance state. If that is the case, do you
> have any ideas as to the best way to model it in Linux? Should we even
> bother if it mostly has a minimal performance gain for typical workloads?

For latency constraints, we have dev_pm_qos. This will make the genpd
governor, to prevent deeper idle states for the device and its
corresponding PM domain (genpd). But that doesn't sound like a good
fit here.

If you are right, it rather sounds like there is some kind of
quiescence mode of the memory controller that can be prevented. But I
have no clue, of course. :-)

>
> I'll try to do some latency tests, see if I can make sense of what it's
> actually doing.
>

Kind regards
Uffe

WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Hector Martin <marcan@marcan.st>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Sibi Sankar <sibis@codeaurora.org>,
	Saravana Kannan <saravanak@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Sven Peter <sven@svenpeter.dev>, Marc Zyngier <maz@kernel.org>,
	Mark Kettenis <mark.kettenis@xs4all.nl>,
	Michael Turquette <mturquette@baylibre.com>,
	 Stephen Boyd <sboyd@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	 Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Viresh Kumar <vireshk@kernel.org>,  Nishanth Menon <nm@ti.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 "Rafael J. Wysocki" <rafael@kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	 linux-clk <linux-clk@vger.kernel.org>,
	DTML <devicetree@vger.kernel.org>,
	 Linux PM <linux-pm@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist
Date: Fri, 15 Oct 2021 13:26:35 +0200	[thread overview]
Message-ID: <CAPDyKFpCw1M8bK5T6a+=x-kHaCco88wiRnvUm5Dy90XU360=4A@mail.gmail.com> (raw)
In-Reply-To: <ca820b86-fc12-63b9-ec6b-5823ddd73aba@marcan.st>

On Thu, 14 Oct 2021 at 19:02, Hector Martin <marcan@marcan.st> wrote:
>
> On 14/10/2021 21.55, Ulf Hansson wrote:
> > On Thu, 14 Oct 2021 at 13:43, Hector Martin <marcan@marcan.st> wrote:
> >> I was poking around and noticed the OPP core can already integrate with
> >> interconnect requirements, so perhaps the memory controller can be an
> >> interconnect provider, and the CPU nodes can directly reference it as a
> >> consumer? This seems like a more accurate model of what the hardware
> >> does, and I think I saw some devices doing this already.
> >
> > Yeah, that could work too. And, yes, I agree, it may be a better
> > description of the HW.
> >
> >>
> >> (only problem is I have no idea of the actual bandwidth numbers involved
> >> here... I'll have to run some benchmarks to make sure this isn't just
> >> completely dummy data)
> >>
>
> So... I tried getting bandwidth numbers and failed. It seems these
> registers don't actually affect peak performance in any measurable way.
> I'm also getting almost the same GeekBench scores on macOS with and
> without this mechanism enabled, although there is one subtest that seems
> to show a measurable difference.
>
> My current guess is this is something more subtle (latencies? idle
> timers and such?) than a performance state. If that is the case, do you
> have any ideas as to the best way to model it in Linux? Should we even
> bother if it mostly has a minimal performance gain for typical workloads?

For latency constraints, we have dev_pm_qos. This will make the genpd
governor, to prevent deeper idle states for the device and its
corresponding PM domain (genpd). But that doesn't sound like a good
fit here.

If you are right, it rather sounds like there is some kind of
quiescence mode of the memory controller that can be prevented. But I
have no clue, of course. :-)

>
> I'll try to do some latency tests, see if I can make sense of what it's
> actually doing.
>

Kind regards
Uffe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-10-15 11:27 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 16:56 [RFC PATCH 0/9] Apple SoC CPU P-state switching Hector Martin
2021-10-11 16:56 ` Hector Martin
2021-10-11 16:56 ` [RFC PATCH 1/9] MAINTAINERS: apple: Add apple-mcc and clk-apple-cluster paths Hector Martin
2021-10-11 16:56   ` Hector Martin
2021-10-11 16:57 ` [RFC PATCH 2/9] dt-bindings: memory-controller: Add apple,mcc binding Hector Martin
2021-10-11 16:57   ` [RFC PATCH 2/9] dt-bindings: memory-controller: Add apple, mcc binding Hector Martin
2021-10-12  8:48   ` [RFC PATCH 2/9] dt-bindings: memory-controller: Add apple,mcc binding Krzysztof Kozlowski
2021-10-12  8:48     ` Krzysztof Kozlowski
2021-10-19 22:43     ` Rob Herring
2021-10-19 22:43       ` Rob Herring
2021-10-11 16:57 ` [RFC PATCH 3/9] dt-bindings: clock: Add apple,cluster-clk binding Hector Martin
2021-10-11 16:57   ` Hector Martin
2021-10-12  8:51   ` Krzysztof Kozlowski
2021-10-12  8:51     ` [RFC PATCH 3/9] dt-bindings: clock: Add apple, cluster-clk binding Krzysztof Kozlowski
2021-10-12  9:35     ` [RFC PATCH 3/9] dt-bindings: clock: Add apple,cluster-clk binding Viresh Kumar
2021-10-12  9:35       ` [RFC PATCH 3/9] dt-bindings: clock: Add apple, cluster-clk binding Viresh Kumar
     [not found]       ` <D0DE08FE-562E-4A48-BCA0-9094DAFCA564@marcan.st>
     [not found]         ` <20211012094302.3cownyzr4phxwifs@vireshk-i7>
     [not found]           ` <64584F8C-D49F-41B5-9658-CF8A25186E67@marcan.st>
     [not found]             ` <20211012095735.mhh2lzu52ohtotl6@vireshk-i7>
2021-10-12 13:48               ` [RFC PATCH 3/9] dt-bindings: clock: Add apple,cluster-clk binding Hector Martin
2021-10-12 13:48                 ` [RFC PATCH 3/9] dt-bindings: clock: Add apple, cluster-clk binding Hector Martin
2021-10-14 21:47   ` Stephen Boyd
2021-10-11 16:57 ` [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist Hector Martin
2021-10-11 16:57   ` Hector Martin
2021-10-12  3:21   ` Viresh Kumar
2021-10-12  3:21     ` Viresh Kumar
2021-10-12  5:34     ` Hector Martin
2021-10-12  5:34       ` Hector Martin
2021-10-12  5:51       ` Viresh Kumar
2021-10-12  5:51         ` Viresh Kumar
2021-10-12  5:57         ` Hector Martin
2021-10-12  5:57           ` Hector Martin
2021-10-12  9:26           ` Viresh Kumar
2021-10-12  9:26             ` Viresh Kumar
2021-10-12  9:31             ` Hector Martin "marcan"
2021-10-12  9:31               ` Hector Martin "marcan"
2021-10-12  9:32               ` Viresh Kumar
2021-10-12  9:32                 ` Viresh Kumar
2021-10-14  6:52                 ` Hector Martin
2021-10-14  6:52                   ` Hector Martin
2021-10-14  6:56                   ` Viresh Kumar
2021-10-14  6:56                     ` Viresh Kumar
2021-10-14  7:03                     ` Hector Martin
2021-10-14  7:03                       ` Hector Martin
2021-10-14  7:22                       ` Viresh Kumar
2021-10-14  7:22                         ` Viresh Kumar
2021-10-14  7:23                       ` Hector Martin
2021-10-14  7:23                         ` Hector Martin
2021-10-14 11:08                         ` Ulf Hansson
2021-10-14 11:08                           ` Ulf Hansson
2021-10-14  9:55           ` Ulf Hansson
2021-10-14  9:55             ` Ulf Hansson
2021-10-14 11:43             ` Hector Martin
2021-10-14 11:43               ` Hector Martin
2021-10-14 12:55               ` Ulf Hansson
2021-10-14 12:55                 ` Ulf Hansson
2021-10-14 17:02                 ` Hector Martin
2021-10-14 17:02                   ` Hector Martin
2021-10-15 11:26                   ` Ulf Hansson [this message]
2021-10-15 11:26                     ` Ulf Hansson
2021-10-11 16:57 ` [RFC PATCH 5/9] PM: domains: Add of_genpd_add_provider_simple_noclk() Hector Martin
2021-10-11 16:57   ` Hector Martin
2021-10-11 16:57 ` [RFC PATCH 6/9] memory: apple: Add apple-mcc driver to manage MCC perf in Apple SoCs Hector Martin
2021-10-11 16:57   ` Hector Martin
2021-10-12  7:24   ` kernel test robot
2021-10-12  9:19   ` Krzysztof Kozlowski
2021-10-12  9:19     ` Krzysztof Kozlowski
2021-10-14  6:59     ` Hector Martin
2021-10-14  6:59       ` Hector Martin
2021-10-14  7:36       ` Krzysztof Kozlowski
2021-10-14  7:36         ` Krzysztof Kozlowski
2021-10-14  7:52         ` Hector Martin
2021-10-14  7:52           ` Hector Martin
2021-10-14  8:04           ` Krzysztof Kozlowski
2021-10-14  8:04             ` Krzysztof Kozlowski
2021-10-14  8:31             ` Hector Martin
2021-10-14  8:31               ` Hector Martin
2021-10-11 16:57 ` [RFC PATCH 7/9] clk: apple: Add clk-apple-cluster driver to manage CPU p-states Hector Martin
2021-10-11 16:57   ` Hector Martin
2021-10-13  3:45   ` kernel test robot
2021-10-14 22:07   ` Stephen Boyd
2021-10-17  9:16     ` Hector Martin
2021-10-17  9:16       ` Hector Martin
2021-10-11 16:57 ` [RFC PATCH 8/9] arm64: apple: Select MEMORY and APPLE_MCC Hector Martin
2021-10-11 16:57   ` Hector Martin
2021-10-11 16:57 ` [RFC PATCH 9/9] arm64: apple: Add CPU frequency scaling support for t8103 Hector Martin
2021-10-11 16:57   ` Hector Martin

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='CAPDyKFpCw1M8bK5T6a+=x-kHaCco88wiRnvUm5Dy90XU360=4A@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=alyssa@rosenzweig.io \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=khilman@kernel.org \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.kettenis@xs4all.nl \
    --cc=maz@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=nm@ti.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=sibis@codeaurora.org \
    --cc=sven@svenpeter.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.