Date: Fri, 28 Apr 2017 13:10:21 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: Rainer Duffner <rainer@ultra-secure.de> Cc: freebsd-pkg@freebsd.org Subject: Re: poudriere suggestions Message-ID: <71a8cb99-6c1e-d552-43e2-34b2f1dcd3b3@pinyon.org> In-Reply-To: <4E32A700-BD92-4BF1-A0C4-A7269123A827@ultra-secure.de> References: <20170428144150.4db646cc@rsbsd> <cc5ad61d-0ca4-b6b2-fe53-4662172b4400@pinyon.org> <4E32A700-BD92-4BF1-A0C4-A7269123A827@ultra-secure.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/28/17 12:09, Rainer Duffner wrote: > >> Am 28.04.2017 um 16:29 schrieb Russell L. Carter <rcarter@pinyon.org >> <mailto:rcarter@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71a8cb99-6c1e-d552-43e2-34b2f1dcd3b3>