linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Lukasz Luba <lukasz.luba@arm.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Willy Wolff <willy.mh.wolff.ml@gmail.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>,
	MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	linux-pm@vger.kernel.org,
	"linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4?
Date: Wed, 24 Jun 2020 17:11:33 +0200	[thread overview]
Message-ID: <ef5184ed-00ff-4226-5ece-b0fc8eb16fb6@samsung.com> (raw)
In-Reply-To: <85f5a8c0-7d48-f2cd-3385-c56d662f2c88@arm.com>

Hi All,

On 24.06.2020 12:32, Lukasz Luba wrote:
> I had issues with devfreq governor which wasn't called by devfreq
> workqueue. The old DELAYED vs DEFERRED work discussions and my patches
> for it [1]. If the CPU which scheduled the next work went idle, the
> devfreq workqueue will not be kicked and devfreq governor won't check
> DMC status and will not decide to decrease the frequency based on low
> busy_time.
> The same applies for going up with the frequency. They both are
> done by the governor but the workqueue must be scheduled periodically.

As I have been working on resolving the video mixer IOMMU fault issue
described here: https://patchwork.kernel.org/patch/10861757
I did some investigation of the devfreq operation, mostly on Odroid U3.

My conclusions are similar to what Lukasz says above. I would like to add
that broken scheduling of the performance counters read and the devfreq 
updates seems to have one more serious implication. In each call, which
normally should happen periodically with fixed interval we stop the counters, 
read counter values and start the counters again. But if period between 
calls becomes long enough to let any of the counters overflow, we will
get wrong performance measurement results. My observations are that 
the workqueue job can be suspended for several seconds and conditions for 
the counter overflow occur sooner or later, depending among others 
on the CPUs load.
Wrong bus load measurement can lead to setting too low interconnect bus 
clock frequency and then bad things happen in peripheral devices.

I agree the workqueue issue needs to be fixed. I have some WIP code to use
the performance counters overflow interrupts instead of SW polling and with 
that the interconnect bus clock control seems to work much better.

-- 
Regards,
Sylwester

  parent reply	other threads:[~2020-06-24 15:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 16:47 brocken devfreq simple_ondemand for Odroid XU3/4? Willy Wolff
2020-06-23 19:02 ` Krzysztof Kozlowski
2020-06-23 19:11   ` Krzysztof Kozlowski
2020-06-24  8:01     ` Willy Wolff
2020-06-24  8:14       ` Krzysztof Kozlowski
2020-06-24  8:52         ` Willy Wolff
2020-06-24 10:32     ` Lukasz Luba
2020-06-24 11:18       ` Kamil Konieczny
2020-06-24 12:06         ` Krzysztof Kozlowski
2020-06-24 13:03           ` Lukasz Luba
2020-06-24 13:13             ` Krzysztof Kozlowski
2020-06-24 13:42               ` Lukasz Luba
2020-06-24 15:11       ` Sylwester Nawrocki [this message]
2020-06-25 10:02         ` Lukasz Luba
2020-06-25 11:30           ` Kamil Konieczny
2020-06-25 12:02             ` Lukasz Luba
2020-06-25 12:12               ` Kamil Konieczny
2020-06-26 11:22                 ` Bartlomiej Zolnierkiewicz
2020-06-29  1:43                   ` Chanwoo Choi
2020-06-29 11:52                     ` Lukasz Luba
2020-07-01 15:48                       ` Willy Wolff
2020-06-29 11:34                   ` Lukasz Luba
2020-06-26 17:50           ` Sylwester Nawrocki
2020-06-29 11:41             ` Lukasz Luba
2020-06-29  1:52         ` Chanwoo Choi

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=ef5184ed-00ff-4226-5ece-b0fc8eb16fb6@samsung.com \
    --to=s.nawrocki@samsung.com \
    --cc=cw00.choi@samsung.com \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=willy.mh.wolff.ml@gmail.com \
    /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).