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: Thu, 24 Dec 2015 10:13:18 -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> <567AAC9F dot 5060404 at redhat dot com> <567AC51E dot 2050404 at redhat dot com>
On 12/23/2015 11:00 AM, Florian Weimer wrote:
>> What do you think is the bottleneck here?
>
> On top of the scaling issue of some of the threading tests, it looks as
> if lack of parallelism between subdirectories is the major culprit.
> This means that single-thread performance determines build and test
> times to a large extent.
Interesting. Is it avoidable though?
I do see problems, for example, build and test on a 24 core box is:
real 20m0.705s
user 44m27.832s
sys 30m57.313s
While build and test on a 4 core box is:
real 22m46.742s
user 18m52.517s
sys 12m4.294s
Where I would expect the 24 core box to be much much faster.
Would the next step be to time subdirectories and see which ones
are the slowest?
> math/gen-libm-test.pl is major seralization point during builds (not
> tests). During tests, it's compilation test-tgmath2.c (related to poor
> performance of debugging information generation in GCC, as discussed
> before).
That step is relatively fast, even if were to serialize all operations,
it can't entirely explain the abysmal performance above?
Cheers,
Carlos.