On Fri, May 21, 2021 at 8:03 AM Thomas Huth <th...@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é <f4...@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 >
