[v3] gitlab-ci: Allow using FreeBSD runners

[PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Philippe Mathieu-Daudé 4 years, 7 months ago

If a runner has ccache installed, use it and display statistics
at the end of the build.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 .gitlab-ci.d/buildtest-template.yml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/.gitlab-ci.d/buildtest-template.yml b/.gitlab-ci.d/buildtest-template.yml
index f284d7a0eec..a625c697d3b 100644
--- a/.gitlab-ci.d/buildtest-template.yml
+++ b/.gitlab-ci.d/buildtest-template.yml
@@ -6,13 +6,18 @@
       then
         JOBS=$(sysctl -n hw.ncpu)
         MAKE=gmake
+        PATH=/usr/local/libexec/ccache:$PATH
         ;
       else
         JOBS=$(expr $(nproc) + 1)
         MAKE=make
+        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
         ;
       fi
     - echo "=== Using $JOBS simultaneous jobs ==="
+    - if command -v ccache > /dev/null ; then ccache --zero-stats ; fi
+  after_script:
+    - if command -v ccache > /dev/null ; then ccache --show-stats ; fi
 
 .native_build_job_template:
   stage: build
-- 
2.26.3

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Willian Rampazzo 4 years, 7 months ago

On Wed, May 19, 2021 at 3:46 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> If a runner has ccache installed, use it and display statistics
> at the end of the build.
>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  .gitlab-ci.d/buildtest-template.yml | 5 +++++
>  1 file changed, 5 insertions(+)
>

Reviewed-by: Willian Rampazzo <willianr@redhat.com>

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Thomas Huth 4 years, 7 months ago

On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
> If a runner has ccache installed, use it and display statistics
> at the end of the build.
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>   .gitlab-ci.d/buildtest-template.yml | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/.gitlab-ci.d/buildtest-template.yml b/.gitlab-ci.d/buildtest-template.yml
> index f284d7a0eec..a625c697d3b 100644
> --- a/.gitlab-ci.d/buildtest-template.yml
> +++ b/.gitlab-ci.d/buildtest-template.yml
> @@ -6,13 +6,18 @@
>         then
>           JOBS=$(sysctl -n hw.ncpu)
>           MAKE=gmake
> +        PATH=/usr/local/libexec/ccache:$PATH
>           ;
>         else
>           JOBS=$(expr $(nproc) + 1)
>           MAKE=make
> +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH

That does not make sense for the shared runners yet. We first need something 
to enable the caching there - see my series "Use ccache in the gitlab-CI" 
from April (which is currently stalled unfortunately).

  Thomas

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Philippe Mathieu-Daudé 4 years, 7 months ago

+Stefan/Daniel

On 5/20/21 10:02 AM, Thomas Huth wrote:
> On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
>> If a runner has ccache installed, use it and display statistics
>> at the end of the build.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> ---
>>   .gitlab-ci.d/buildtest-template.yml | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/.gitlab-ci.d/buildtest-template.yml
>> b/.gitlab-ci.d/buildtest-template.yml
>> index f284d7a0eec..a625c697d3b 100644
>> --- a/.gitlab-ci.d/buildtest-template.yml
>> +++ b/.gitlab-ci.d/buildtest-template.yml
>> @@ -6,13 +6,18 @@
>>         then
>>           JOBS=$(sysctl -n hw.ncpu)
>>           MAKE=gmake
>> +        PATH=/usr/local/libexec/ccache:$PATH
>>           ;
>>         else
>>           JOBS=$(expr $(nproc) + 1)
>>           MAKE=make
>> +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
> 
> That does not make sense for the shared runners yet. We first need
> something to enable the caching there - see my series "Use ccache in the
> gitlab-CI" from April (which is currently stalled unfortunately).

TL;DR: I don't think we should restrict our templates to shared runners.

I don't think mainstream interest for shared runners use should limit
forks... This is a great improvement for contributors having to use
private/custom runner, see this example:

https://gitlab.com/philmd/qemu/-/jobs/1255197705
cache hit (direct)                  1529
cache hit (preprocessed)             736
cache miss                           855
cache hit rate                     72.60 %

Having been caught 2 times for testing as hard as crypto miner, I
can not rely on shared runners for my workflow.

Beside, the recent announcement:
https://about.gitlab.com/blog/2021/05/17/prevent-crypto-mining-abuse/
"starting May 17, 2021, GitLab will require new free users to provide a
valid credit or debit card number in order to use shared runners on
GitLab.com."

On this report only 17/142 countries are listed as having more than
50% of their population with a credit card:
https://www.theglobaleconomy.com/rankings/people_with_credit_cards/
and 60 with a debit card:
https://www.theglobaleconomy.com/rankings/people_with_debit_cards/

We have some contributors in countries with low percentage. I don't
think we should start a poll to verify, but I do think relying on
shared runners without proposing free alternative is discriminatory
to a part of our community.

I am very open to alternatives to improve the CI/testing situation.

Regards,

Phil.

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Thomas Huth 4 years, 7 months ago

On 20/05/2021 13.27, Philippe Mathieu-Daudé wrote:
> +Stefan/Daniel
> 
> On 5/20/21 10:02 AM, Thomas Huth wrote:
>> On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
>>> If a runner has ccache installed, use it and display statistics
>>> at the end of the build.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>> ---
>>>    .gitlab-ci.d/buildtest-template.yml | 5 +++++
>>>    1 file changed, 5 insertions(+)
>>>
>>> diff --git a/.gitlab-ci.d/buildtest-template.yml
>>> b/.gitlab-ci.d/buildtest-template.yml
>>> index f284d7a0eec..a625c697d3b 100644
>>> --- a/.gitlab-ci.d/buildtest-template.yml
>>> +++ b/.gitlab-ci.d/buildtest-template.yml
>>> @@ -6,13 +6,18 @@
>>>          then
>>>            JOBS=$(sysctl -n hw.ncpu)
>>>            MAKE=gmake
>>> +        PATH=/usr/local/libexec/ccache:$PATH
>>>            ;
>>>          else
>>>            JOBS=$(expr $(nproc) + 1)
>>>            MAKE=make
>>> +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
>>
>> That does not make sense for the shared runners yet. We first need
>> something to enable the caching there - see my series "Use ccache in the
>> gitlab-CI" from April (which is currently stalled unfortunately).
> 
> TL;DR: I don't think we should restrict our templates to shared runners.

I'm certainly not voting for restricting ourselves to only use shared 
runners here - but my concern is that this actually *slows* down the shared 
runners even more! (sorry, I should have elaborated on that in my previous 
mail already)

When I was experimenting with ccache in the shared runners, I saw that the 
jobs are running even slower with ccache enabled as long as the cache is not 
populated yet. You only get a speedup afterwards. So if you add this now 
without also adding the possibility to store the cache persistently, the 
shared runners will try to populate the cache each time just to throw away 
the results afterwards again. Thus all the shared runners only get slower 
without any real benefit here.

Thus we either need to get ccache working properly for the shared runners 
first, or you have to think of a different way of enabling ccache for the 
non-shared runners, so that it does not affect the shared runners negatively.

  Thomas

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Daniel P. Berrangé 4 years, 7 months ago

On Fri, May 21, 2021 at 12:48:21PM +0200, Thomas Huth wrote:
> On 20/05/2021 13.27, Philippe Mathieu-Daudé wrote:
> > +Stefan/Daniel
> > 
> > On 5/20/21 10:02 AM, Thomas Huth wrote:
> > > On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
> > > > If a runner has ccache installed, use it and display statistics
> > > > at the end of the build.
> > > > 
> > > > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > > > ---
> > > >    .gitlab-ci.d/buildtest-template.yml | 5 +++++
> > > >    1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/.gitlab-ci.d/buildtest-template.yml
> > > > b/.gitlab-ci.d/buildtest-template.yml
> > > > index f284d7a0eec..a625c697d3b 100644
> > > > --- a/.gitlab-ci.d/buildtest-template.yml
> > > > +++ b/.gitlab-ci.d/buildtest-template.yml
> > > > @@ -6,13 +6,18 @@
> > > >          then
> > > >            JOBS=$(sysctl -n hw.ncpu)
> > > >            MAKE=gmake
> > > > +        PATH=/usr/local/libexec/ccache:$PATH
> > > >            ;
> > > >          else
> > > >            JOBS=$(expr $(nproc) + 1)
> > > >            MAKE=make
> > > > +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
> > > 
> > > That does not make sense for the shared runners yet. We first need
> > > something to enable the caching there - see my series "Use ccache in the
> > > gitlab-CI" from April (which is currently stalled unfortunately).
> > 
> > TL;DR: I don't think we should restrict our templates to shared runners.
> 
> I'm certainly not voting for restricting ourselves to only use shared
> runners here - but my concern is that this actually *slows* down the shared
> runners even more! (sorry, I should have elaborated on that in my previous
> mail already)
> 
> When I was experimenting with ccache in the shared runners, I saw that the
> jobs are running even slower with ccache enabled as long as the cache is not
> populated yet. You only get a speedup afterwards. So if you add this now
> without also adding the possibility to store the cache persistently, the
> shared runners will try to populate the cache each time just to throw away
> the results afterwards again. Thus all the shared runners only get slower
> without any real benefit here.
> 
> Thus we either need to get ccache working properly for the shared runners
> first, or you have to think of a different way of enabling ccache for the
> non-shared runners, so that it does not affect the shared runners
> negatively.

Is there anything functional holding up your previous full cccache support
series from last month ? Or is it just lack of reviews ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Thomas Huth 4 years, 7 months ago

On 21/05/2021 12.50, Daniel P. Berrangé wrote:
> On Fri, May 21, 2021 at 12:48:21PM +0200, Thomas Huth wrote:
>> On 20/05/2021 13.27, Philippe Mathieu-Daudé wrote:
>>> +Stefan/Daniel
>>>
>>> On 5/20/21 10:02 AM, Thomas Huth wrote:
>>>> On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
>>>>> If a runner has ccache installed, use it and display statistics
>>>>> at the end of the build.
>>>>>
>>>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>>>> ---
>>>>>     .gitlab-ci.d/buildtest-template.yml | 5 +++++
>>>>>     1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/.gitlab-ci.d/buildtest-template.yml
>>>>> b/.gitlab-ci.d/buildtest-template.yml
>>>>> index f284d7a0eec..a625c697d3b 100644
>>>>> --- a/.gitlab-ci.d/buildtest-template.yml
>>>>> +++ b/.gitlab-ci.d/buildtest-template.yml
>>>>> @@ -6,13 +6,18 @@
>>>>>           then
>>>>>             JOBS=$(sysctl -n hw.ncpu)
>>>>>             MAKE=gmake
>>>>> +        PATH=/usr/local/libexec/ccache:$PATH
>>>>>             ;
>>>>>           else
>>>>>             JOBS=$(expr $(nproc) + 1)
>>>>>             MAKE=make
>>>>> +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
>>>>
>>>> That does not make sense for the shared runners yet. We first need
>>>> something to enable the caching there - see my series "Use ccache in the
>>>> gitlab-CI" from April (which is currently stalled unfortunately).
>>>
>>> TL;DR: I don't think we should restrict our templates to shared runners.
>>
>> I'm certainly not voting for restricting ourselves to only use shared
>> runners here - but my concern is that this actually *slows* down the shared
>> runners even more! (sorry, I should have elaborated on that in my previous
>> mail already)
>>
>> When I was experimenting with ccache in the shared runners, I saw that the
>> jobs are running even slower with ccache enabled as long as the cache is not
>> populated yet. You only get a speedup afterwards. So if you add this now
>> without also adding the possibility to store the cache persistently, the
>> shared runners will try to populate the cache each time just to throw away
>> the results afterwards again. Thus all the shared runners only get slower
>> without any real benefit here.
>>
>> Thus we either need to get ccache working properly for the shared runners
>> first, or you have to think of a different way of enabling ccache for the
>> non-shared runners, so that it does not affect the shared runners
>> negatively.
> 
> Is there anything functional holding up your previous full cccache support
> series from last month ? Or is it just lack of reviews ?

It's basically the problems mentioned in the cover letter and Stefan's 
comment here:

  https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg02219.html

The series needs more love and more testing, if it's feasible with the 
gitlab-CI architecture at all to use ccache in a good way ... if we don't 
get a real speedup by the patches, it's certainly not worth the effort to 
integrate this...

If someone wants to have a try to improve the patch series, your help is 
certainly welcome - since at least I personally lack the time and motivation 
to improve this any further.

  Thomas

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Daniel P. Berrangé 4 years, 7 months ago

On Fri, May 21, 2021 at 01:02:51PM +0200, Thomas Huth wrote:
> On 21/05/2021 12.50, Daniel P. Berrangé wrote:
> > On Fri, May 21, 2021 at 12:48:21PM +0200, Thomas Huth wrote:
> > > On 20/05/2021 13.27, Philippe Mathieu-Daudé wrote:
> > > > +Stefan/Daniel
> > > > 
> > > > On 5/20/21 10:02 AM, Thomas Huth wrote:
> > > > > On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
> > > > > > If a runner has ccache installed, use it and display statistics
> > > > > > at the end of the build.
> > > > > > 
> > > > > > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > > > > > ---
> > > > > >     .gitlab-ci.d/buildtest-template.yml | 5 +++++
> > > > > >     1 file changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/.gitlab-ci.d/buildtest-template.yml
> > > > > > b/.gitlab-ci.d/buildtest-template.yml
> > > > > > index f284d7a0eec..a625c697d3b 100644
> > > > > > --- a/.gitlab-ci.d/buildtest-template.yml
> > > > > > +++ b/.gitlab-ci.d/buildtest-template.yml
> > > > > > @@ -6,13 +6,18 @@
> > > > > >           then
> > > > > >             JOBS=$(sysctl -n hw.ncpu)
> > > > > >             MAKE=gmake
> > > > > > +        PATH=/usr/local/libexec/ccache:$PATH
> > > > > >             ;
> > > > > >           else
> > > > > >             JOBS=$(expr $(nproc) + 1)
> > > > > >             MAKE=make
> > > > > > +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
> > > > > 
> > > > > That does not make sense for the shared runners yet. We first need
> > > > > something to enable the caching there - see my series "Use ccache in the
> > > > > gitlab-CI" from April (which is currently stalled unfortunately).
> > > > 
> > > > TL;DR: I don't think we should restrict our templates to shared runners.
> > > 
> > > I'm certainly not voting for restricting ourselves to only use shared
> > > runners here - but my concern is that this actually *slows* down the shared
> > > runners even more! (sorry, I should have elaborated on that in my previous
> > > mail already)
> > > 
> > > When I was experimenting with ccache in the shared runners, I saw that the
> > > jobs are running even slower with ccache enabled as long as the cache is not
> > > populated yet. You only get a speedup afterwards. So if you add this now
> > > without also adding the possibility to store the cache persistently, the
> > > shared runners will try to populate the cache each time just to throw away
> > > the results afterwards again. Thus all the shared runners only get slower
> > > without any real benefit here.
> > > 
> > > Thus we either need to get ccache working properly for the shared runners
> > > first, or you have to think of a different way of enabling ccache for the
> > > non-shared runners, so that it does not affect the shared runners
> > > negatively.
> > 
> > Is there anything functional holding up your previous full cccache support
> > series from last month ? Or is it just lack of reviews ?
> 
> It's basically the problems mentioned in the cover letter and Stefan's
> comment here:
> 
>  https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg02219.html

I'm not sure I understand why Stefan thinks gitlab's caching doesn't
benefit ccache. We add ccache for libvirt GitLab CI, and AFAIR it
sped up our builds significantly.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Philippe Mathieu-Daudé 4 years, 7 months ago

On 5/21/21 1:53 PM, Daniel P. Berrangé wrote:
> On Fri, May 21, 2021 at 01:02:51PM +0200, Thomas Huth wrote:
>> On 21/05/2021 12.50, Daniel P. Berrangé wrote:
>>> On Fri, May 21, 2021 at 12:48:21PM +0200, Thomas Huth wrote:
>>>> On 20/05/2021 13.27, Philippe Mathieu-Daudé wrote:
>>>>> +Stefan/Daniel
>>>>>
>>>>> On 5/20/21 10:02 AM, Thomas Huth wrote:
>>>>>> On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
>>>>>>> If a runner has ccache installed, use it and display statistics
>>>>>>> at the end of the build.
>>>>>>>
>>>>>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>>>>>> ---
>>>>>>>     .gitlab-ci.d/buildtest-template.yml | 5 +++++
>>>>>>>     1 file changed, 5 insertions(+)
>>>>>>>
>>>>>>> diff --git a/.gitlab-ci.d/buildtest-template.yml
>>>>>>> b/.gitlab-ci.d/buildtest-template.yml
>>>>>>> index f284d7a0eec..a625c697d3b 100644
>>>>>>> --- a/.gitlab-ci.d/buildtest-template.yml
>>>>>>> +++ b/.gitlab-ci.d/buildtest-template.yml
>>>>>>> @@ -6,13 +6,18 @@
>>>>>>>           then
>>>>>>>             JOBS=$(sysctl -n hw.ncpu)
>>>>>>>             MAKE=gmake
>>>>>>> +        PATH=/usr/local/libexec/ccache:$PATH
>>>>>>>             ;
>>>>>>>           else
>>>>>>>             JOBS=$(expr $(nproc) + 1)
>>>>>>>             MAKE=make
>>>>>>> +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
>>>>>>
>>>>>> That does not make sense for the shared runners yet. We first need
>>>>>> something to enable the caching there - see my series "Use ccache in the
>>>>>> gitlab-CI" from April (which is currently stalled unfortunately).
>>>>>
>>>>> TL;DR: I don't think we should restrict our templates to shared runners.
>>>>
>>>> I'm certainly not voting for restricting ourselves to only use shared
>>>> runners here - but my concern is that this actually *slows* down the shared
>>>> runners even more! (sorry, I should have elaborated on that in my previous
>>>> mail already)
>>>>
>>>> When I was experimenting with ccache in the shared runners, I saw that the
>>>> jobs are running even slower with ccache enabled as long as the cache is not
>>>> populated yet. You only get a speedup afterwards. So if you add this now
>>>> without also adding the possibility to store the cache persistently, the
>>>> shared runners will try to populate the cache each time just to throw away
>>>> the results afterwards again. Thus all the shared runners only get slower
>>>> without any real benefit here.
>>>>
>>>> Thus we either need to get ccache working properly for the shared runners
>>>> first, or you have to think of a different way of enabling ccache for the
>>>> non-shared runners, so that it does not affect the shared runners
>>>> negatively.
>>>
>>> Is there anything functional holding up your previous full cccache support
>>> series from last month ? Or is it just lack of reviews ?
>>
>> It's basically the problems mentioned in the cover letter and Stefan's
>> comment here:
>>
>>  https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg02219.html
> 
> I'm not sure I understand why Stefan thinks gitlab's caching doesn't
> benefit ccache. We add ccache for libvirt GitLab CI, and AFAIR it
> sped up our builds significantly.

I think Stefan is referring to a comment I made, when using both
shared runners and dedicated runners (what I'm currently testing)
various jobs are stuck transferring artifacts/cache {FROM, TO}
{shared, dedicated} runners at the same time, which is sub-optimal
because it saturate the dedicated runner network link.

If we want to use pool of runners to restrict transfer between
runners from the same physical pool, then it because a maintenance
headache.

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Willian Rampazzo 4 years, 7 months ago

On Fri, May 21, 2021 at 8:03 AM Thomas Huth <thuth@redhat.com> wrote:
>
> On 21/05/2021 12.50, Daniel P. Berrangé wrote:
> > On Fri, May 21, 2021 at 12:48:21PM +0200, Thomas Huth wrote:
> >> On 20/05/2021 13.27, Philippe Mathieu-Daudé wrote:
> >>> +Stefan/Daniel
> >>>
> >>> On 5/20/21 10:02 AM, Thomas Huth wrote:
> >>>> On 19/05/2021 20.45, Philippe Mathieu-Daudé wrote:
> >>>>> If a runner has ccache installed, use it and display statistics
> >>>>> at the end of the build.
> >>>>>
> >>>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >>>>> ---
> >>>>>     .gitlab-ci.d/buildtest-template.yml | 5 +++++
> >>>>>     1 file changed, 5 insertions(+)
> >>>>>
> >>>>> diff --git a/.gitlab-ci.d/buildtest-template.yml
> >>>>> b/.gitlab-ci.d/buildtest-template.yml
> >>>>> index f284d7a0eec..a625c697d3b 100644
> >>>>> --- a/.gitlab-ci.d/buildtest-template.yml
> >>>>> +++ b/.gitlab-ci.d/buildtest-template.yml
> >>>>> @@ -6,13 +6,18 @@
> >>>>>           then
> >>>>>             JOBS=$(sysctl -n hw.ncpu)
> >>>>>             MAKE=gmake
> >>>>> +        PATH=/usr/local/libexec/ccache:$PATH
> >>>>>             ;
> >>>>>           else
> >>>>>             JOBS=$(expr $(nproc) + 1)
> >>>>>             MAKE=make
> >>>>> +        PATH=/usr/lib/ccache:/usr/lib64/ccache:$PATH
> >>>>
> >>>> That does not make sense for the shared runners yet. We first need
> >>>> something to enable the caching there - see my series "Use ccache in the
> >>>> gitlab-CI" from April (which is currently stalled unfortunately).
> >>>
> >>> TL;DR: I don't think we should restrict our templates to shared runners.
> >>
> >> I'm certainly not voting for restricting ourselves to only use shared
> >> runners here - but my concern is that this actually *slows* down the shared
> >> runners even more! (sorry, I should have elaborated on that in my previous
> >> mail already)
> >>
> >> When I was experimenting with ccache in the shared runners, I saw that the
> >> jobs are running even slower with ccache enabled as long as the cache is not
> >> populated yet. You only get a speedup afterwards. So if you add this now
> >> without also adding the possibility to store the cache persistently, the
> >> shared runners will try to populate the cache each time just to throw away
> >> the results afterwards again. Thus all the shared runners only get slower
> >> without any real benefit here.
> >>

I was in favor of adding the changes and benefiting custom runners
until I saw your reply. In this case, I agree we should investigate
how these changes affect shared runners.

> >> Thus we either need to get ccache working properly for the shared runners
> >> first, or you have to think of a different way of enabling ccache for the
> >> non-shared runners, so that it does not affect the shared runners
> >> negatively.
> >
> > Is there anything functional holding up your previous full cccache support
> > series from last month ? Or is it just lack of reviews ?
>
> It's basically the problems mentioned in the cover letter and Stefan's
> comment here:
>
>   https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg02219.html
>
> The series needs more love and more testing, if it's feasible with the
> gitlab-CI architecture at all to use ccache in a good way ... if we don't
> get a real speedup by the patches, it's certainly not worth the effort to
> integrate this...
>
> If someone wants to have a try to improve the patch series, your help is
> certainly welcome - since at least I personally lack the time and motivation
> to improve this any further.

Do you mind if I play with your patch series? I do not promise 100% of
my time working on it, but I was thinking about dedicating some time
to ccache before your patch series.

>
>   Thomas
>

Re: [PATCH v3 4/6] gitlab-ci: Add ccache in $PATH and display statistics

Posted by Thomas Huth 4 years, 7 months ago

On 21/05/2021 14.36, Willian Rampazzo wrote:
> On Fri, May 21, 2021 at 8:03 AM Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 21/05/2021 12.50, Daniel P. Berrangé wrote:
[...]
>>> Is there anything functional holding up your previous full cccache support
>>> series from last month ? Or is it just lack of reviews ?
>>
>> It's basically the problems mentioned in the cover letter and Stefan's
>> comment here:
>>
>>    https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg02219.html
>>
>> The series needs more love and more testing, if it's feasible with the
>> gitlab-CI architecture at all to use ccache in a good way ... if we don't
>> get a real speedup by the patches, it's certainly not worth the effort to
>> integrate this...
>>
>> If someone wants to have a try to improve the patch series, your help is
>> certainly welcome - since at least I personally lack the time and motivation
>> to improve this any further.
> 
> Do you mind if I play with your patch series? I do not promise 100% of
> my time working on it, but I was thinking about dedicating some time
> to ccache before your patch series.

I certainly don't mind! If you get it running well enough so that the total 
runtime decreases, that would be really great!

  Thomas