diff mbox series

[v3,2/2] ci: Add a test for a non-LTO build

Message ID 20220803121301.v3.2.Ib592f574bd629316a4da239b054fdad8af2658a3@changeid
State Accepted
Commit 1aa168ca8fa472620a0aa72ff10b6eb4d0414e03
Delegated to: Tom Rini
Headers show
Series [v3,1/2] Makefile: Allow LTO to be disabled for a build | expand

Commit Message

Simon Glass Aug. 3, 2022, 6:13 p.m. UTC
Check that sandbox builds and runs tests OK with LTO disabled.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 .azure-pipelines.yml | 4 ++++
 .gitlab-ci.yml       | 7 +++++++
 2 files changed, 11 insertions(+)

Comments

Simon Glass Aug. 7, 2022, 3:48 p.m. UTC | #1
Hi Tom,

On Wed, 3 Aug 2022 at 12:13, Simon Glass <sjg@chromium.org> wrote:
>
> Check that sandbox builds and runs tests OK with LTO disabled.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
>  .azure-pipelines.yml | 4 ++++
>  .gitlab-ci.yml       | 7 +++++++
>  2 files changed, 11 insertions(+)
>

Another little snippet - it seems that CI performance for the world
builds has dropped 20% - 30% with LTO enabled. With tui I used to see
just over 1 build a second; now it is running at about 0.78 and kaki
has gone from close to 0.5 to 0.29.

I wonder if ,in CI, we should just build a selection of boards with
LTO, switching the world builds to non-LTO? The problem is that we may
hit code size limits in SPL.

Regards,
Simon
Tom Rini Aug. 8, 2022, 4:09 p.m. UTC | #2
On Sun, Aug 07, 2022 at 09:48:01AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 3 Aug 2022 at 12:13, Simon Glass <sjg@chromium.org> wrote:
> >
> > Check that sandbox builds and runs tests OK with LTO disabled.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> >  .azure-pipelines.yml | 4 ++++
> >  .gitlab-ci.yml       | 7 +++++++
> >  2 files changed, 11 insertions(+)
> >
> 
> Another little snippet - it seems that CI performance for the world
> builds has dropped 20% - 30% with LTO enabled. With tui I used to see
> just over 1 build a second; now it is running at about 0.78 and kaki
> has gone from close to 0.5 to 0.29.
> 
> I wonder if ,in CI, we should just build a selection of boards with
> LTO, switching the world builds to non-LTO? The problem is that we may
> hit code size limits in SPL.

I'm not sure how you're measuring this. We don't enable LTO by default
anywhere other than sandbox, it's opt-in for a few platforms still.
Simon Glass Aug. 9, 2022, 7:51 p.m. UTC | #3
Hi Tom,

On Mon, 8 Aug 2022 at 10:09, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Aug 07, 2022 at 09:48:01AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 3 Aug 2022 at 12:13, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Check that sandbox builds and runs tests OK with LTO disabled.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > ---
> > >
> > > (no changes since v1)
> > >
> > >  .azure-pipelines.yml | 4 ++++
> > >  .gitlab-ci.yml       | 7 +++++++
> > >  2 files changed, 11 insertions(+)
> > >
> >
> > Another little snippet - it seems that CI performance for the world
> > builds has dropped 20% - 30% with LTO enabled. With tui I used to see
> > just over 1 build a second; now it is running at about 0.78 and kaki
> > has gone from close to 0.5 to 0.29.
> >
> > I wonder if ,in CI, we should just build a selection of boards with
> > LTO, switching the world builds to non-LTO? The problem is that we may
> > hit code size limits in SPL.
>
> I'm not sure how you're measuring this. We don't enable LTO by default
> anywhere other than sandbox, it's opt-in for a few platforms still.

I just assumed that is why, since it slows incremental builds down so
much. But perhaps something else is going on? I can try to bisect it,
I suppose, if I take tui offline for a bit.

Regards,
Simon
Tom Rini Aug. 9, 2022, 8:10 p.m. UTC | #4
On Tue, Aug 09, 2022 at 01:51:13PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 8 Aug 2022 at 10:09, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Aug 07, 2022 at 09:48:01AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 3 Aug 2022 at 12:13, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Check that sandbox builds and runs tests OK with LTO disabled.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > ---
> > > >
> > > > (no changes since v1)
> > > >
> > > >  .azure-pipelines.yml | 4 ++++
> > > >  .gitlab-ci.yml       | 7 +++++++
> > > >  2 files changed, 11 insertions(+)
> > > >
> > >
> > > Another little snippet - it seems that CI performance for the world
> > > builds has dropped 20% - 30% with LTO enabled. With tui I used to see
> > > just over 1 build a second; now it is running at about 0.78 and kaki
> > > has gone from close to 0.5 to 0.29.
> > >
> > > I wonder if ,in CI, we should just build a selection of boards with
> > > LTO, switching the world builds to non-LTO? The problem is that we may
> > > hit code size limits in SPL.
> >
> > I'm not sure how you're measuring this. We don't enable LTO by default
> > anywhere other than sandbox, it's opt-in for a few platforms still.
> 
> I just assumed that is why, since it slows incremental builds down so
> much. But perhaps something else is going on? I can try to bisect it,
> I suppose, if I take tui offline for a bit.

If you think there's something consistent here, yeah, it'd be good to
track it down. For me, complete runs go from between 45min to 1h20min,
with a few longer outliers.
Tom Rini Sept. 3, 2022, 1:54 a.m. UTC | #5
On Wed, Aug 03, 2022 at 12:13:09PM -0600, Simon Glass wrote:

> Check that sandbox builds and runs tests OK with LTO disabled.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/next, thanks!
diff mbox series

Patch

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index bc2b437bd99..e542a45dfe0 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -243,6 +243,9 @@  stages:
         sandbox_clang:
           TEST_PY_BD: "sandbox"
           OVERRIDE: "-O clang-13"
+        sandbox_nolto:
+          TEST_PY_BD: "sandbox"
+          BUILD_ENV: "NO_LTO=1"
         sandbox_spl:
           TEST_PY_BD: "sandbox_spl"
           TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or test_spl"
@@ -354,6 +357,7 @@  stages:
           export TEST_PY_ID="${TEST_PY_ID}"
           export TEST_PY_TEST_SPEC="${TEST_PY_TEST_SPEC}"
           export OVERRIDE="${OVERRIDE}"
+          export BUILD_ENV="${BUILD_ENV}"
           EOF
           cat << "EOF" >> test.sh
           # the below corresponds to .gitlab-ci.yml "before_script"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f9cd4175079..80b5d29f953 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -33,6 +33,7 @@  stages:
   script:
     # If we've been asked to use clang only do one configuration.
     - export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD}
+    - echo BUILD_ENV ${BUILD_ENV}
     - tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W -e
         --board ${TEST_PY_BD} ${OVERRIDE}
     - cp ~/grub_x86.efi $UBOOT_TRAVIS_BUILD_DIR/
@@ -248,6 +249,12 @@  sandbox with clang test.py:
     OVERRIDE: "-O clang-13"
   <<: *buildman_and_testpy_dfn
 
+sandbox without LTO test.py:
+  variables:
+    TEST_PY_BD: "sandbox"
+    BUILD_ENV: "NO_LTO=1"
+  <<: *buildman_and_testpy_dfn
+
 sandbox_spl test.py:
   variables:
     TEST_PY_BD: "sandbox_spl"