From: Willy Wolff <willy.mh.wolff.ml@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
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:52:17 +0200 [thread overview]
Message-ID: <20200624085217.5km2iexitfgclsev@macmini.local> (raw)
In-Reply-To: <20200624081438.GA20603@pi3>
On 2020-06-24-10-14-38, Krzysztof Kozlowski wrote:
> 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...
OK, I will read the code then.
>
> >
> > 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.
Yes obvisouly. I was just describing a bit the microbenchmark and the memory pattern
access. I was suggesting that a random pattern will break the effectiveness of the
prefetcher, and as such we have a worst case situation on the memory bus.
>
> Best regards,
> Krzysztof
next prev parent reply other threads:[~2020-06-24 8:52 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 [this message]
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=20200624085217.5km2iexitfgclsev@macmini.local \
--to=willy.mh.wolff.ml@gmail.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 \
/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