Hi Fedor,
Okay. Thanks for the info, and for sharing the issue ticket below.

Jun


On Thu, Jun 15, 2023 at 8:39 PM Fedor Korotkov <fedor@cirruslabs.org> wrote:
Yes, we had some issues with the migration but everything should be working now even better than before. Please check this comment for details.

On Thu, Jun 15, 2023 at 10:13 AM Jun Aruga (he / him) <jaruga@redhat.com> wrote:
Hi Febor,

Thank you for your help and investigation! It seems your email was not sent to the ruby-core@ruby-lang.org mailing list, as the setting of the mailing list only accepts the email from a subscribed person. So, I reply with your email message.

> ... Right now it only uses 1 core:

This can be improved in our Cirrus CI configuration file.

> On a side, within the next week or two we are planning to migrate from Graviton 2 CPUs to more performant offering of Ampere CPUs on Google Cloud.

I see. We observed the following Cirrus CI didn't start even after 1 hour. Do you know the reason?

I hope that this will be improved after the migration.

Jun Aruga

On Mon, Jun 12, 2023 at 3:33 PM Fedor Korotkov <fedor@cirruslabs.org> wrote:
Hey Jun,

I was just writing a response when you followed up. :-)

As far as the configuration, we don't see anything suspicious in it. The only thing that might be improved is making compilation utilize all the cores. Right now it only uses 1 core:

Screenshot 2023-06-12 at 9.24.09 AM.png

As for the clang performance, we don't have any insights. From the graphs it just seems to be working slower than your gcc variant.

On a side, within the next week or two we are planning to migrate from Graviton 2 CPUs to more performant offering of Ampere CPUs on Google Cloud.

On Mon, Jun 12, 2023 at 9:22 AM Jun Aruga (he / him) <jaruga@redhat.com> wrote:
Dear Cirrus CI customer support,

Thank you for helping us (Ruby project)!
Could you check the following message about the issue in Cirrus CI in
the Ruby project?

I noticed sending an email to the customer support email is better
than sending an email to a person's email. So, I am sending the
message to the support email again.
Long story short, we see Cirrus CI is unstable in our cases (running 4
cases in Arm), and we want your advice for our .cirrus.yml file to
fill our needs.

https://cirrus-ci.org/support/
> The best way to ask general questions about particular use cases is to email our support team at support+ci@cirruslabs.org. Our support team is trying our best to respond ASAP, but there is no guarantee on a response time unless your organization enrolls in Priority Support.

Kind regards,
Jun

On Fri, Jun 9, 2023 at 12:57 PM Jun Aruga (he / him) <jaruga@redhat.com> wrote:
>
> Hello Fedor @ Cirrus CI,
> CC: Ruby Core mailing list.
>
> Thank you for helping the Ruby project for adding Cirrus CI. I am
> sending an email to ask you for help to improve the Cirrus CI. We are
> running 4 parallel jobs (2 gcc cases ARM, 2 clang cases ARM) in the
> Cirrus CI.
> However, I am seeing some challenges such as the queue is stopping,
> and the clang cases are 2 or 3 times slower than gcc cases. So, today
> we stopped the 2 clang cases in a compromised way.
>
> Could you check our .cirrus.yml file on the reverted commit, and give
> advice to us and ideally just send a pull-request to the master branch
> for that?
>
> https://github.com/ruby/ruby/blob/master/.cirrus.yml
>
> ```
> $ git clone https://github.com/ruby/ruby.git
> $ cd ruby
> $ git revert 72f07f0a5f882e87e305d668587152fa209a0568.
> ```
>
> I suspect the current `cpu:` value might not be correct. And we may
> need the following change.
>
> ```
> diff --git a/.cirrus.yml b/.cirrus.yml
> index be76e4ab4a..8b820be1a2 100644
> --- a/.cirrus.yml
> +++ b/.cirrus.yml
> @@ -16,10 +16,10 @@ task:
>      image: ghcr.io/ruby/ruby-ci-image:$CC
>      # Define the used cpu core in each matrix task. We can use total 16 cpu
>      # cores in entire matrix. [cpu] = [total cpu: 16] / [number of tasks]
> -    cpu: 8
> +    cpu: 4
>      # We can request maximum 4 GB per cpu.
>      # [memory per task] = [memory per cpu: 4 GB] * [cpu]
> -    memory: 32G
> +    memory: 16G
>    env:
>      CIRRUS_CLONE_DEPTH: 50
>      optflags: '-O1'
> @@ -71,10 +71,10 @@ yjit_task:
>      image: ghcr.io/ruby/ruby-ci-image:$CC
>      # Define the used cpu core in each matrix task. We can use total 16 cpu
>      # cores in entire matrix. [cpu] = [total cpu: 16] / [number of tasks]
> -    cpu: 8
> +    cpu: 4
>      # We can request maximum 4 GB per cpu.
>      # [memory per task] = [memory per cpu: 4 GB] * [cpu]
> -    memory: 32G
> +    memory: 16G
>    env:
>      CIRRUS_CLONE_DEPTH: 50
>      optflags: '-O1'
> ```
>
> Thank you for your help!
>
> --
> Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
> See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
> the timezone.

--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for
the timezone.

--
You received this message because you are subscribed to the Google Groups "Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to support+unsubscribe@cirruslabs.org.
To view this discussion on the web visit https://groups.google.com/a/cirruslabs.org/d/msgid/support/CAHE_3CiT_59xrbUjabvfXh-O348vr9PWKe0EnEdmsRHLgqt2-A%40mail.gmail.com.


--

Fedor Korotkov

Founder at Cirrus Labs

@fedor



--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for the timezone.


--

Fedor Korotkov

Founder at Cirrus Labs

@fedor



--
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for the timezone.