This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Large parallel glibc builds.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 23 Dec 2015 09:15:59 -0500
- Subject: Re: Large parallel glibc builds.
- Authentication-results: sourceware.org; auth=none
- References: <5679A3BE dot 2060303 at redhat dot com> <567AA3B4 dot 3030301 at redhat dot com>
On 12/23/2015 08:37 AM, Florian Weimer wrote:
> On 12/22/2015 08:25 PM, Carlos O'Donell wrote:
>> Community,
>>
>> I am consistently doing parallel (-j56) builds for glibc
>> on Intel Xeon CPU E5-2697 v3 @ 2.60GHz (2 socket x 14 cores x 2HT).
>>
>> I have not seen any failures or artifacts that look like hazards
>> or races in our makefiles.
>>
>> Is anyone else using larger boxes for builds and still seeing
>> problems?
>
> I still see the linknamespace failures
>
> FAIL: conform/ISO/assert.h/linknamespace
> FAIL: conform/ISO/ctype.h/linknamespace
> FAIL: conform/ISO/errno.h/linknamespace
> FAIL: conform/ISO/locale.h/linknamespace
> â
>
> reported here first:
>
> <https://sourceware.org/ml/libc-alpha/2015-05/msg00490.html>
Please file a bug about this so we can track it (like the locale
issue H.J. reported).
> Some tests have problems because they run into scalability issues
> (thread creation is particularly slow on large machines, likely due to
> mmap being extremely expensive).
If we could find out which tests have problems that would be useful.
> The build itself is fine.
>
> All this was observed on an 80-core, 160-thread x86-64 machine, with
> -j160, running Fedora 23. Parallelization is extremely low.
> PARALLELMFLAGS does not make a difference.
>
> Consequently, this machine is not significantly faster for building
> glibc than an average laptop, and testing is in fact quite a bit slower.
What do you think is the bottleneck here?
Cheers,
Carlos.