On Tue, Oct 25, 2022 at 03:01:07PM +0900, Mike Hommey wrote: > On Tue, Oct 25, 2022 at 02:57:23PM +0900, ISHIKAWA,chiaki wrote: > > On 2022/10/25 2:48, ISHIKAWA,chiaki wrote: > > > > > > > > > > > Build System and Mach Environment > > > > > > > > * > > > > > > > > Starting with Bug 1746462 > > > > <https://bugzilla.mozilla.org/show_bug.cgi?id=1746462>you can use > > > > the mold linker for linking Mozilla Firefox on most Linux > > > > distributions. MacOS support will come shortly. > > > > > > > > > > I tested "mold" for building C-C thunderbird. > > > > > > I was impressed. > > > > > > |The I/O speed during linking "libxul", the large libary, is near the > > > max bandwidth of my local disk setup (on a linux guest within VirtualBox > > > hosted under Windows 10). > > > I watched the xosview's disk I/O activity with amusement. > > > As is described in Bugzilla, then all of a sudden the multiple CPU's got > > > busy (I have assigned 7 vCPUs to my linux guest and 16GB of memory > > > assigned) and linking was over. > > > In contrast, with GNU gold which I have been using, I see prolonged I/O > > > not near the maximum bandwidth and single CPU getting busy during long > > > linking. > > > > > > Of course, the linking is only a small portion of the whole build > > > process, but it *IS* a lengthy process. > > > > > > This is a great work. > > > > > > Keep the good work going! > > > > > > Chiaki > > > > > > > I think this has a large impact on tryserver. > > > > Before, I have noticed that typical build has a very long tail end of single > > CPU usage. This was the long linking process, I think. > > I mentioned once on one of the mailing list (or bugzilla?) that the link > > ought to get started as early as possible to avoid this. > > It seems it was started rather early after all, but slow linking showed this > > behavior. > > However, with mold, the link process actually ends rather early and such a > > tail end of single CPU usage is not visible at all now. > > > > In my local setup where I monitor the compilation through emacs shell > > buffer, the verbose output of housechore commands (it seems build was > > creating jar files under various directories) > > is printed for like several seconds very quickly at the end (very light CPU > > consumption way after the burst of heavy parallel usage is gone) and the > > build ends then. > > I have never seen such end behavior of build before. It used to be a very > > long link process at the end and these housechore commands ended well before > > link ended. > > > > I believe someone ought to check the job workload profile in the tryserver > > once mold becomes widely used. > > It can possibly ends the jobs quicker, or the parallel CPU usage and large > > memory footprint may impact the farm negatively. > > It all depends on the workload profile. In my single build environment, mold > > performs very well to my pleasant surprise. > > > > I wonder if it will be available under Windows (!?). > > THAT will change the CPU/IO workload of tryserver computer farm. > > "tryserver" is using lld, which is not that much slower than mold. > Linking is not what's costly there.
Local builds default to lld too, by the way. Mike -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/20221025060253.g5g7ee3hgjwqldys%40glandium.org.
