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 1/3] ARM: exynos_defconfig: Enable SCHED_MC
Date: Fri, 31 Jan 2020 21:33:24 +0100 [thread overview]
Message-ID: <20200131203324.GA27510@kozik-lap> (raw)
In-Reply-To: <ae021317-8fda-2bb2-2080-1304fda1420c@arm.com>
On Fri, Jan 31, 2020 at 03:59:30PM +0000, Lukasz Luba wrote:
> Hi Krzysztof,
>
> Thank you for your review, please see my comments below.
>
> On 1/31/20 12:47 PM, Krzysztof Kozlowski wrote:
> > On Mon, 27 Jan 2020 at 22:55, <lukasz.luba@arm.com> wrote:
> > >
> > > From: Lukasz Luba <lukasz.luba@arm.com>
> > >
> > > Since the 'capacities-dmips-mhz' are present in the CPU nodes, make use of
> > > this knowledge in smarter decisions during scheduling.
> > >
> > > The values in 'capacities-dmips-mhz' are normilized, this means that i.e.
> > > when CPU0's capacities-dmips-mhz=100 and CPU1's 'capacities-dmips-mhz'=50,
> > > cpu0 is twice fast as CPU1, at the same frequency. The proper hirarchy
> > > in sched_domain topology could exploit the SoC architecture advantages
> > > like big.LITTLE.
> >
> > I do not quite get how this is related to rationale behind changing defconfig...
>
> It is not strictly about EAS, it is useful in general for big.LITTLE
> platform with clusters.
>
> >
> > > Enabling the SCHED_MC will create two levels in
> > > sched_domain hierarchy, which might be observed in:
> >
> > This is looks more convincing... but still what is the need? To work with EAS?
>
> It is not only for EAS, but in general for the scheduler (load balance,
> task's wake-up path, etc). The scheduler algorithms iterate CPUs in the
> sched groups. To make better decisions, the information about MC domain
> is needed. More about the scheduler domains and i.e. load_balance()
> you can find here:
>
> https://www.kernel.org/doc/html/latest/scheduler/sched-domains.html
Ahhh, I see, it's independent of later patches. Somehow I had impression
it is a prerequisite...
>
> >
> > > grep . /proc/sys/kernel/sched_domain/cpu*/domain*/{name,flags}
> > > /proc/sys/kernel/sched_domain/cpu0/domain0/name:MC
> > > /proc/sys/kernel/sched_domain/cpu0/domain1/name:DIE
> > > ...
> > > /proc/sys/kernel/sched_domain/cpu0/domain0/flags:575
> > > /proc/sys/kernel/sched_domain/cpu0/domain1/flags:4223
> >
> > Not related to defconfig change and not visible after this commit.
>
> Without this patch there is only one domain: 'domain0' -> 'DIE'
> cat /proc/sys/kernel/sched_domain/cpu0/domain0/name
> DIE
>
> When you apply this patch you will get two: 'domain0, 'domain1'
> grep . /proc/sys/kernel/sched_domain/cpu0/domain?/name
>
> /proc/sys/kernel/sched_domain/cpu0/domain0/name:MC
> /proc/sys/kernel/sched_domain/cpu0/domain1/name:DIE
>
> I can remove it this information, but it is the most important
> to spot this difference out.
>
> This is also the main reason I haven't merge the patch 1 + 3.
Indeed. I thought that these will pop up at the end of the patchset, my
bad.
I do not see big benefits of adding these outputs as proofs of working
SCHED_MC because they are kind of obvious. It is not a measurement but
report of current system state. However they don't harm neither, so I am
fine with it.
However please us in commit msg also the name of turned on option, next
or instead of SCHED_MC. The options might be sometimes cryptic or too
vague and the name actually easily expresses what you want enable.
next prev parent reply other threads:[~2020-01-31 20:33 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 [this message]
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
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=20200131203324.GA27510@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).