poudriere suggestions

[Russell L. Carter]

On 04/28/17 12:09, Rainer Duffner wrote:
> 
>> Am 28.04.2017 um 16:29 schrieb Russell L. Carter <rcarter at pinyon.org 
>> <mailto:rcarter at pinyon.org>>:
>>
>> There is a tension between the (mostly) single-threaded ports and
>> the monsters like libreoffice, chromium, webkit-*, firefox, and
>> llvm*.
> 
> 
> So, it’s not possible to speed up the build of libreoffice by 
> parallelizing it?

I must have not been clear.  The "monsters" (so to speak), are fully
parallelizable, but if you set PARALLEL_JOBS to a high number (e.g. the
number of cores/threads) and also set MAKE_JOBS_NUMBER in
poudriere.d/make.conf to a high number (e.g. the number of
cores/threads), then you might end up with a portion
of the build scheduling MAKE_JOBS_NUMBER*PARALLEL_JOBS cores/threads.
That will bring many systems to their knees.

So for instance, via a lot of observation, I've found that
PARALLEL_JOBS=6, MAKE_JOBS_NUMBER=7 works best for my 32 thread Xeons.
This has the disadvantage that when running a lot of single threaded
jobs through only PARALLEL_JOBS number of threads are active, but
I keep the peak load down far enough that the big multithreaded
jobs minimize thrashing and maximize efficiency.

Similarly, if at the end of the poudriere bulk build there are 2
long running jobs, it does not matter that PARALLEL_JOBS is set
higher; you will only get  2*MAKE_JOBS_NUMBER available threads
working on the those two jobs (and nothing else will run,
everything else is complete).

So I see a lot of either 7 or 2*7 load average for up to a
couple of hours on my 32 thread box.  Suboptimal.

I would like to get hard numbers on this but that would be a really
big effort given the computational effort in a 4-8 hr poudriere run.

What eventually needs to happen is that MAKE_JOBS_NUMBER changes
according to the current number of buildable JOBS and the available
cores/threads (which is a function of the current working set of
jobs at the time of scheduling this job).  This will require
reservations and priorities and tracking the current thread
demand, but I suppose that's a long way off yet.  HPC schedulers
do this.  It turns out this is a supercomputer problem, kinda
cool.

> I only build a 2000-ish subset of ports - and libreoffice (together with 
> webkit-gtk2) takes more time than anything else.
> Or rather, these take more time than the rest, combined.

I've got a similar number subset, but it seems to be chromium that's the
real time sink.

> 
> I’ve got a 2x6 core Xeon and 64GB RAM.

hth,
Russell