From: Ryan Eatmon <reatmon@ti.com>
To: Andrew Davis <afd@ti.com>, Denys Dmytriyenko <denis@denix.org>
Cc: Denys Dmytriyenko <denys@konsulko.com>, <meta-ti@lists.yoctoproject.org>
Subject: Re: [meta-ti][master/kirkstone][PATCH] conf: machine: k3: Use Cortex-A53/A72 CPU tune
Date: Tue, 20 Feb 2024 09:00:12 -0600 [thread overview]
Message-ID: <853c4cbd-aed8-44f0-85e4-5a8a8362a424@ti.com> (raw)
In-Reply-To: <d7c539d7-f9ff-46e4-9ae8-ca825e8f3fd1@ti.com>
On 2/20/2024 8:31 AM, Andrew Davis wrote:
> On 2/16/24 2:23 PM, Denys Dmytriyenko wrote:
>> Unfortunately, NAK.
>>
>> This is considered an antisocial behavior for a BSP in the Yocto Project
>> world. And the performance benefit is questionable with 1%-2%, if at all.
>>
>
> This stated when a potential customer noticed building and running some
> benchmarks (linpack for instance) on our SDK were being out-performed by
> some other vendors. Even though on paper our platforms should have been
> the better performing ones.
>
> After investigating it turns out these other vendors have these tune
> options in their BSP layers, causing the performance discrepancy.
>
> So the performance here, even of a couple percent, is very important.
>
>> The proper place for any extra optimization tunes is in a distro
>> config. Maybe
>> even by end customer's final product, not a reference distro.
>>
>> Consider a distro that supports multiple HW platforms and uses
>> multiple BSPs
>> besides meta-ti - YoE, AGL, etc. You do want a common denominator
>> tunes in
>> order to get the most binary re-use across the platforms.
>>
>
> If one wants binary re-use they can override the tune. Otherwise maybe
> they should be using Debian or some other binary distro. The main selling
> point for Yocto IMHO is customizing like this. The best part of rebuilding
> everything from scratch every time for every machine is we can have these
> machine specific tunings.
>
>> For example, AGL goes to some extreme lengths to override such custom
>> tunes
>> set by misbehaving BSPs and it's quite ugly.
>>
>
> Then we should work to make it easier to override for those folks, not
> simply
> leave this performance on the table.
>
>> And moreover, we've gone through this motion in the past many years
>> ago when
>> we had our ARMv7 platforms set to their corresponding cortex-a8/a9/a15
>> tunes
>> by default, but eventually ended up setting a common ARMv7 tune:
>>
>> DEFAULTTUNE ?= "armv7athf-neon"
>>
>> So, you should either leave the current arch-arm64.inc inclusion as
>> is, or if
>> you insist on including tune-cortexa72-cortexa53.inc, set the default
>> tune
>> back to plain aarch64:
>>
>> DEFAULTTUNE ?= "aarch64"
>>
>
> I see our friends over in meta-xilinx are doing machine specific
> DEFAULTTUNEs.
> I was thinking of matching that to keep our BSP performance competitive.
> But
> as a compromise and to avoid "antisocial behavior" as you say, I think I
> can
> live with DEFAULTTUNE ?= "aarch64".
>
> Will resend with that.
So, if we include the more targeted tuning file, but set DEFAULTUNE to
the generic, then how do our builds use the more targeted tuning? Is
that something we have to set in the local.conf as part of our builds?
Or is this some sort of magic that occurs that gets the correct thing?
> Andrew
>
>>
>> On Thu, Feb 15, 2024 at 03:26:13PM -0600, Andrew Davis via
>> lists.yoctoproject.org wrote:
>>> All current K3 devices use either A53 or A72. Use the compile tune
>>> configuration specific for these to allow the compiler to make
>>> better optimizations.
>>>
>>> Signed-off-by: Andrew Davis <afd@ti.com>
>>> ---
>>> meta-ti-bsp/conf/machine/include/k3.inc | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/meta-ti-bsp/conf/machine/include/k3.inc
>>> b/meta-ti-bsp/conf/machine/include/k3.inc
>>> index 2415f0ba..7c3579af 100644
>>> --- a/meta-ti-bsp/conf/machine/include/k3.inc
>>> +++ b/meta-ti-bsp/conf/machine/include/k3.inc
>>> @@ -3,7 +3,7 @@
>>> require conf/machine/include/ti-soc.inc
>>> SOC_FAMILY:append = ":k3"
>>> -require conf/machine/include/arm/arch-arm64.inc
>>> +require conf/machine/include/arm/armv8a/tune-cortexa72-cortexa53.inc
>>> BBMULTICONFIG += "k3r5"
>>> --
>>> 2.39.2
--
Ryan Eatmon reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
prev parent reply other threads:[~2024-02-20 15:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 21:26 [meta-ti][master/kirkstone][PATCH] conf: machine: k3: Use Cortex-A53/A72 CPU tune Andrew Davis
2024-02-16 7:07 ` [EXTERNAL] " Limaye, Aniket
2024-02-16 20:23 ` Denys Dmytriyenko
2024-02-20 14:31 ` Andrew Davis
2024-02-20 15:00 ` Ryan Eatmon [this message]
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=853c4cbd-aed8-44f0-85e4-5a8a8362a424@ti.com \
--to=reatmon@ti.com \
--cc=afd@ti.com \
--cc=denis@denix.org \
--cc=denys@konsulko.com \
--cc=meta-ti@lists.yoctoproject.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 read-only IMAP folder(s) and NNTP newsgroup(s).