From: Krzysztof Kozlowski <krzk@kernel.org>
To: 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>,
Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4?
Date: Wed, 24 Jun 2020 10:14:38 +0200 [thread overview]
Message-ID: <20200624081438.GA20603@pi3> (raw)
In-Reply-To: <20200624080117.fzgowkpgyhs6tbzx@macmini.local>
On Wed, Jun 24, 2020 at 10:01:17AM +0200, Willy Wolff wrote:
> Hi Krzysztof,
> Thanks to look at it.
>
> mem_gov is /sys/class/devfreq/10c20000.memory-controller/governor
>
> Here some numbers after increasing the running time:
>
> Running using simple_ondemand:
> Before:
> From : To
> : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms)
> * 165000000: 0 0 0 0 0 0 0 4 4528600
> 206000000: 5 0 0 0 0 0 0 0 57780
> 275000000: 0 5 0 0 0 0 0 0 50060
> 413000000: 0 0 5 0 0 0 0 0 46240
> 543000000: 0 0 0 5 0 0 0 0 48970
> 633000000: 0 0 0 0 5 0 0 0 47330
> 728000000: 0 0 0 0 0 0 0 0 0
> 825000000: 0 0 0 0 0 5 0 0 331300
> Total transition : 34
>
>
> After:
> From : To
> : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms)
> * 165000000: 0 0 0 0 0 0 0 4 5098890
> 206000000: 5 0 0 0 0 0 0 0 57780
> 275000000: 0 5 0 0 0 0 0 0 50060
> 413000000: 0 0 5 0 0 0 0 0 46240
> 543000000: 0 0 0 5 0 0 0 0 48970
> 633000000: 0 0 0 0 5 0 0 0 47330
> 728000000: 0 0 0 0 0 0 0 0 0
> 825000000: 0 0 0 0 0 5 0 0 331300
> Total transition : 34
>
> With a running time of:
> LITTLE => 283.699 s (680.877 c per mem access)
> big => 284.47 s (975.327 c per mem access)
I see there were no transitions during your memory test.
>
> And when I set to the performance governor:
> Before:
> From : To
> : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms)
> 165000000: 0 0 0 0 0 0 0 5 5099040
> 206000000: 5 0 0 0 0 0 0 0 57780
> 275000000: 0 5 0 0 0 0 0 0 50060
> 413000000: 0 0 5 0 0 0 0 0 46240
> 543000000: 0 0 0 5 0 0 0 0 48970
> 633000000: 0 0 0 0 5 0 0 0 47330
> 728000000: 0 0 0 0 0 0 0 0 0
> * 825000000: 0 0 0 0 0 5 0 0 331350
> Total transition : 35
>
> After:
> From : To
> : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms)
> 165000000: 0 0 0 0 0 0 0 5 5099040
> 206000000: 5 0 0 0 0 0 0 0 57780
> 275000000: 0 5 0 0 0 0 0 0 50060
> 413000000: 0 0 5 0 0 0 0 0 46240
> 543000000: 0 0 0 5 0 0 0 0 48970
> 633000000: 0 0 0 0 5 0 0 0 47330
> 728000000: 0 0 0 0 0 0 0 0 0
> * 825000000: 0 0 0 0 0 5 0 0 472980
> Total transition : 35
>
> With a running time of:
> LITTLE: 68.8428 s (165.223 c per mem access)
> big: 71.3268 s (244.549 c per mem access)
>
>
> I see some transition, but not occuring during the benchmark.
> I haven't dive into the code, but maybe it is the heuristic behind that is not
> well defined? If you know how it's working that would be helpfull before I dive
> in it.
Sorry, don't know that much. It seems it counts time between overflow of
DMC perf events and based on this bumps up the frequency.
Maybe your test does not fit well in current formula? Maybe the formula
has some drawbacks...
>
> I run your test as well, and indeed, it seems to work for large bunch of memory,
> and there is some delay before making a transition (seems to be around 10s).
> When you kill memtester, it reduces the freq stepwisely every ~10s.
>
> Note that the timing shown above account for the critical path, and the code is
> looping on reading only, there is no write in the critical path.
> Maybe memtester is doing writes and devfreq heuristic uses only write info?
>
You mentioned that you want to cut the prefetcher to have direct access
to RAM. But prefetcher also accesses the RAM. He does not get the
contents from the air. Although this is unrelated to the problem
because your pattern should kick ondemand as well.
Best regards,
Krzysztof
next prev parent reply other threads:[~2020-06-24 8:14 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 [this message]
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
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=20200624081438.GA20603@pi3 \
--to=krzk@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=kgene@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).