Closed Bug 1334940 Opened 3 years ago Closed Last year
Re-enable SCCACHE for linux64-ccov builds
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20170126200443 Steps to reproduce: Run a build on taskcluster with sccache enabled. For example, see: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8002f88014f819ce34055db8ecf72c0e1ceb2b4a&selectedJob=68153184 (232kB gcno archive) Actual results: The produced "gcno" archive is missing most of the "gcno" files, and is undersized. Expected results: Build running with sccache should properly track the "gcno" files. When the final "gcno" archive is created as an artifact, it should be around ~75mB
Backstory: 1. linux64-ccov builds were producing incomplete gcno issues 2. Cause was determined to be incorrect sccache interaction: https://bugzilla.mozilla.org/show_bug.cgi?id=1332917#c18 3. sccache is being disabled for linux64-ccov builds: https://bugzilla.mozilla.org/show_bug.cgi?id=1334402
Ted, Chris, I think this is pretty important for build times, right? Do you know what kind of improvement would be expected by using sccache? I've filed https://github.com/mozilla/sccache/issues/258 to add support to sccache.
See Also: → https://github.com/mozilla/sccache/issues/258
Somewhere in this ballpark, presumably: https://treeherder.mozilla.org/perf.html#/graphs?series=mozilla-inbound,1682429,1,2&series=mozilla-inbound,1582370,1,2 The "plain" builds build without sccache (for measuring build system times without the noise introduced by sccache caching). You can see that the "build times opt plain" measurement is fairly consistent, and the "build times opt" measurement (which does use sccache) is quite a bit lower but variable.
I don't have any more info on this. As long as they only run in a few configurations I don't think the efficiency of these builds would be a big concern from an infrastructure capacity standpoint.
I'm working on https://github.com/mozilla/sccache/issues/258. 1. Here's a try build without changing anything: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6572946785b53fc9959a28183eb6299195d16cfd 2. Here's a try build that just enables sccache, without patching it (to see if the problem is still there): https://treeherder.mozilla.org/#/jobs?repo=try&revision=f27039c3af59f5524ef9acacb6349951ca8d5c63 3. And here's a try build that uses the patched sccache that I've been working on: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8046c858ca85cc80016e5db6520cd08e99d0015 The gcno archives for build #1 and #3 are roughly the same, 75.9mb. I'll update with build #2 once it's done.
Assignee: nobody → tvijiala
Status: NEW → ASSIGNED
Summary: Re-enable and SCCACHE with linux64-ccov, and configure to not lose "gcno" files → Re-enable SCCACHE for linux64-ccov builds
Interesting enough, build #2 produces a gcno archive of roughly the same size as the other ones, 75.9mb, but it's missing some files. Builds #1 and #3 have the same files.
Comment on attachment 8991977 [details] Bug 1334940 - Re-enable SCCACHE for linux64-ccov. https://reviewboard.mozilla.org/r/256876/#review264400 Thanks for fixing the sccache issue!
Attachment #8991977 - Flags: review?(ted) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/f41fb72f94b6 Re-enable SCCACHE for linux64-ccov. r=ted
You need to log in before you can comment on or make changes to this bug.