Date: Thu, 26 Jan 2017 16:36:23 +0000 From: krad <kraduk@gmail.com> To: Kevin Oberman <rkoberman@gmail.com> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Walter Parker <walterp@gmail.com> Subject: Re: Building Kernel and World with -j Message-ID: <CALfReyeMxToVLr7=ZhdpCKFOvoVZoY-1E_s-MLqOGW4Y8jO6Og@mail.gmail.com> In-Reply-To: <CAN6yY1tX2w7M8%2BVK5gVtW%2BUDOwa8_0z1MrbBOfTjJ2WhjdxgGA@mail.gmail.com> References: <CAMPTd_A%2Be6JCJ8SPLGVh4M2Jb=ZLqHDWN9y8JLcVHgWO0=zJ8Q@mail.gmail.com> <44k29l27f2.fsf@lowell-desk.lan> <CAN6yY1tX2w7M8%2BVK5gVtW%2BUDOwa8_0z1MrbBOfTjJ2WhjdxgGA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I use these options in my src.conf WITH_FAST_DEPEND=yes WITH_CCACHE_BUILD=yes I can often get build times of about 9 min but can got upto about 30 mins in jenkins depending on how much has changed. This is on a i5-3570K. It does have 32GB and ssd l2arc. Those times are for a buildworld, buildkernel packages for pkgbase. and j is set to 5 On 23 January 2017 at 18:09, Kevin Oberman <rkoberman@gmail.com> wrote: > On Mon, Jan 23, 2017 at 6:10 AM, Lowell Gilbert < > freebsd-stable-local@be-well.ilk.org> wrote: > > > Walter Parker <walterp@gmail.com> writes: > > > > > For decades there has always been a warning not to do parallel builds > of > > > the kernel or the world (Linux kernel builds also suggest not to do > > this). > > > > > > Every once in a while, I see people post about 5 minutes. This only > way I > > > can see this happening is by doing a parallel build (-j 16 on a Xeon > > > Monster box). > > > > > > Are parallel builds safe? If not, what are actual risk factors and can > > they > > > be mitigated? > > > > As a general rule, it's safe. But don't report failures from a > > parallel build. > > > > This is not so much an issue of parallel builds being unsupported > > as of the logs being harder to read. > > > Use of parallel builds of world and kernel are and have been supported > since at least 10.0. If a parallel build fails, the first step is usually > to do a single-job build. If it succeeds, there is a bug in the make > scripts that should be reported. If the single-job build also fails, a bug > should be reported with any errors included from the non-parallel build as > the parallel build makes the error context very difficult or even > impossible to determine from the log. > > Generally, I think the number of jobs should be slightly greater than the > number of available CPU threads. Back in 10.0 days I ran some tests that > showed the for 4 and 8 thread systems the improvements for large numbers of > jobs peaked at about CPU thread count + 2 and significantly larger numbers > of jobs caused a slight deterioration in performance. This was not true on > early hyper-threaded CPUs which did not effectively optimize > hyper-threading and things may have changed in the 6 or 7 years since I > tested and may be very different for systems with large numbers of threads > seen in servers today. > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALfReyeMxToVLr7=ZhdpCKFOvoVZoY-1E_s-MLqOGW4Y8jO6Og>