Date: Fri, 28 Apr 2017 07:29:11 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-pkg@freebsd.org Subject: Re: poudriere suggestions Message-ID: <cc5ad61d-0ca4-b6b2-fe53-4662172b4400@pinyon.org> In-Reply-To: <20170428144150.4db646cc@rsbsd> References: <20170428144150.4db646cc@rsbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/28/17 04:41, Beeblebrox via freebsd-pkg wrote:
> Hello.
[...]
> * The build que optimization in poudriere might consider port build
> length as a parameter, so that all build jails get full usage. I
> sometimes see 2 or 3 jails idle because poudriere is waiting on an
> ongoing build, whereas the port in question could have been built
> much sooner in the process but smaller ports had been queued.
There is a tension between the (mostly) single-threaded ports and
the monsters like libreoffice, chromium, webkit-*, firefox, and
llvm*. I recently built up a (used) dual E5-2650 (32 threads) w/
128GB of RAM to study the problem because my FX-8300 (8 threads) w/
32GB of RAM was starting to take regularly more than 8 hrs w/
e.g. PARALLEL_JOBS=4 and MAKE_JOBS_NUMBER=3. Any higher parallelism
and the build runs out of swap (standard 2GB) and takes forever.
However, that configuration leaves lots and lots of space waiting,
similar to what you have observed.
With a few overnights in on the new box I am now running
PARALLEL_JOBS=6, MAKE_JOBS_NUMBER=7, w/ build times (not repeatable
workloads, nature of the beast) around 4 hours. Still, I see lots
of idle in the beginning stages (mostly single-threaded) and
chromium trudges along with 7 cores for a long time at the end.
For throughput to improve, MAKE_JOBS_NUMBER and PARALLEL_JOBS need to
be a bit smarter. I think a worthy experiment might be to dynamically
generate MAKE_JOBS_NUMBER like so:
MAKE_JOBS_NUMBER(current scheduling step) =
NCORES
- CURRENT_ACTIVE_NJOBS(single threaded)
- CURRENT_ACTIVE_NJOBS(multi threaded)
* MAKE_JOBS_NUMBER(previous scheduling step)
Even this has problems though; chromium could get launched with just
a thread or two, and then the waiting would begin. But it's a start.
It's a fun, and not easy to solve problem. Optimal dynamic bin
packing. I suspect google has spent a lot of time working on it...
The HPC crowd have been working on it for 40 years.
Russell
> Thanks
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cc5ad61d-0ca4-b6b2-fe53-4662172b4400>