Message ID | 20241208190741.4192601-1-trini@konsulko.com |
---|---|
Headers | show |
Series | Enable arm64 host support in Gitlab | expand |
Hi Tom, On Sun, 8 Dec 2024 at 12:07, Tom Rini <trini@konsulko.com> wrote: > > Hey all, > > First, thanks to Simon Glass and also Linaro, we now have access to a > few fast arm64 host machines in our Gitlab instance, to use as CI > runners. This series finishes the work that I pushed earlier and Simon > had started that enables arm64 hosts to be used for most things now. > > The first notable change, especially if you use this on your own Gitlab > instance is that "DEFAULT_TAG" is now unused and we instead have: > - DEFAULT_ALL_TAG: > - DEFAULT_ARM64_TAG: > - DEFAULT_AMD64_TAG: > - DEFAULT_FAST_AMD64_TAG: > > This lets us say that some jobs can be run on all runners, because they > are small enough that anything we'd connect to CI is fast enough and it > also does not depend on the underlying host architecture. Next we have > tags for any arm64 host, or any amd64 host. Finally, we have a tag for > fast amd64 hosts. What these last three are for is that we have a few > jobs that need to run on amd64 hosts and so we have to restrict them > there, but we also have now reworked the world build jobs to build > (almost) everything in a single job and on the fast amd64 machines this > is still as quick as the old way was, in practice. > > To reach this point, we say that the Xtensa jobs can only run on amd64 > hosts. Our targets only work with the binary-only toolchain and so this > is a reasonable limit and we exclude them from the world build jobs. We > also need to deal with ensuring the right toolchain is used regardless > what the host architecture is and that we don't use the host toolchain > by accident. Finally, because some of these changes needed to be worked > out in the linter, fix some of the general warnings that notes as well. I haven't tried out this series. Does this handle running multiple test.py runs at once? For me that ends up providing a large improvement in CI times (down to about 35 mins with just two fast runners). Regards, Simon
On Mon, Dec 09, 2024 at 08:00:33AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 8 Dec 2024 at 12:07, Tom Rini <trini@konsulko.com> wrote: > > > > Hey all, > > > > First, thanks to Simon Glass and also Linaro, we now have access to a > > few fast arm64 host machines in our Gitlab instance, to use as CI > > runners. This series finishes the work that I pushed earlier and Simon > > had started that enables arm64 hosts to be used for most things now. > > > > The first notable change, especially if you use this on your own Gitlab > > instance is that "DEFAULT_TAG" is now unused and we instead have: > > - DEFAULT_ALL_TAG: > > - DEFAULT_ARM64_TAG: > > - DEFAULT_AMD64_TAG: > > - DEFAULT_FAST_AMD64_TAG: > > > > This lets us say that some jobs can be run on all runners, because they > > are small enough that anything we'd connect to CI is fast enough and it > > also does not depend on the underlying host architecture. Next we have > > tags for any arm64 host, or any amd64 host. Finally, we have a tag for > > fast amd64 hosts. What these last three are for is that we have a few > > jobs that need to run on amd64 hosts and so we have to restrict them > > there, but we also have now reworked the world build jobs to build > > (almost) everything in a single job and on the fast amd64 machines this > > is still as quick as the old way was, in practice. > > > > To reach this point, we say that the Xtensa jobs can only run on amd64 > > hosts. Our targets only work with the binary-only toolchain and so this > > is a reasonable limit and we exclude them from the world build jobs. We > > also need to deal with ensuring the right toolchain is used regardless > > what the host architecture is and that we don't use the host toolchain > > by accident. Finally, because some of these changes needed to be worked > > out in the linter, fix some of the general warnings that notes as well. > > I haven't tried out this series. Does this handle running multiple > test.py runs at once? For me that ends up providing a large > improvement in CI times (down to about 35 mins with just two fast > runners). That's a per-runner configuration option and so orthogonal to this series. Given the breakdown between "all" jobs and "fast" jobs, throwing a bunch of the small and short "all" jobs on a runner also doing a world build should just be a few minutes slow down all around and overall noise.