devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: kgene@kernel.org, linux-arm-kernel@lists.infradead.org,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	myungjoo.ham@samsung.com, kyungmin.park@samsung.com,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	robh+dt@kernel.org, mark.rutland@arm.com,
	"Bartłomiej Żołnierkiewicz" <b.zolnierkie@samsung.com>,
	dietmar.eggemann@arm.com
Subject: Re: [PATCH 3/3] ARM: exynos_defconfig: Enable Energy Model framework
Date: Fri, 31 Jan 2020 21:41:18 +0100	[thread overview]
Message-ID: <20200131204118.GA27284@kozik-lap> (raw)
In-Reply-To: <db3f2554-288d-81ab-2373-1447367ba673@arm.com>

On Fri, Jan 31, 2020 at 05:30:46PM +0000, Lukasz Luba wrote:
 
> > 
> > >                  |-----------------------------------------------|---------------
> > >                  | performance   | SchedUtil     | SchedUtil     | performance
> > >                  | governor      | governor      | governor      | governor
> > >                  |               | w/o EAS       | w/ EAS        |
> > > ----------------|---------------|---------------|---------------|---------------
> > > hackbench w/ PL | 12.7s         | 11.7s         | 12.0s         | 13.0s - 12.2s
> > > hackbench w/o PL| 9.2s          | 8.1s          | 8.2s          | 9.2s - 8.4s
> > 
> > Why does the performance different before and after this patch?
> 
> Probably due to better locality and cache utilization. I can see that
> there is ~700k context switches vs ~450k and ~160k migrations vs ~50k.
> If you need to communicate two threads in different clusters, it will go
> through CCI.

Mhmm... I was not specific - I mean, "performance governor". All this
you mentioned should not differ between performance governor before and
after. However once you have 12.7, then 13.0 - 12.2. Unless multi-core
scheduler affects it... but then these numbers here are not showing
only this change, but also the SCHED_MC effect.  In such case each of
commits should be coming with their own numbers.

> As mentioned in response to patch 1/3. The fist patch would create MC
> domain, something different than Energy Model or EAS. The decisions in
> the scheduler would be different.
> 
> I can merge 1/3 and 3/3 if you like, though.

I understand now that their independent. Still, they are part of one
goal to tune the scheduler for Exynos platform. Splitting these looks
too much, like enabling multiple drivers one after another.

However if you provide numbers for each of cases (before patches, multi
core scheduler, energy model with DTS), then I see benefit of splitting
it.  Each commit would have its own rationale.  I am not sure if it is
worth such investigation - that's just defconfig... distros might ignore
it anyway.

Best regards,
Krzysztof


  reply	other threads:[~2020-01-31 20:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27 21:54 [PATCH 0/3] Enable Odroid-XU3/4 to use Energy Model and Energy Aware Scheduler lukasz.luba
2020-01-27 21:54 ` [PATCH 1/3] ARM: exynos_defconfig: Enable SCHED_MC lukasz.luba
2020-01-31 12:47   ` Krzysztof Kozlowski
2020-01-31 15:59     ` Lukasz Luba
2020-01-31 20:33       ` Krzysztof Kozlowski
2020-01-27 21:54 ` [PATCH 2/3] ARM: dts: exynos: Add Exynos5422 CPU dynamic-power-coefficient information lukasz.luba
2020-01-31 13:05   ` Krzysztof Kozlowski
2020-01-31 16:42     ` Lukasz Luba
2020-01-27 21:54 ` [PATCH 3/3] ARM: exynos_defconfig: Enable Energy Model framework lukasz.luba
2020-01-31 13:16   ` Krzysztof Kozlowski
2020-01-31 17:30     ` Lukasz Luba
2020-01-31 20:41       ` Krzysztof Kozlowski [this message]
2020-02-05 12:49         ` Lukasz Luba
2020-02-06 12:59           ` Krzysztof Kozlowski
2020-02-06 14:15             ` Lukasz Luba
2020-01-31 13:30   ` Bartlomiej Zolnierkiewicz
2020-01-31 13:31     ` Krzysztof Kozlowski
2020-01-31 13:47       ` Bartlomiej Zolnierkiewicz
2020-01-31 13:48         ` Bartlomiej Zolnierkiewicz
2020-01-31 17:38     ` Lukasz Luba

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=20200131204118.GA27284@kozik-lap \
    --to=krzk@kernel.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dietmar.eggemann@arm.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=mark.rutland@arm.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=robh+dt@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).