summaryrefslogtreecommitdiffstats
path: root/linux/linux-ext-xenomai.mk
diff options
context:
space:
mode:
authorYann E. MORIN <yann.morin.1998@free.fr>2013-05-10 03:56:01 +0000
committerPeter Korsgaard <jacmet@sunsite.dk>2013-05-11 22:49:59 +0200
commitdf8d52fb025b8f48bd34344e2987eba3757f966c (patch)
tree4c6b1a7aa095acf11adcca63dea37052d0386c4a /linux/linux-ext-xenomai.mk
parent31002cb40323dcc2aa7b6a50b85e5a3c24b2a5d6 (diff)
downloadbuildroot-novena-df8d52fb025b8f48bd34344e2987eba3757f966c.tar.gz
buildroot-novena-df8d52fb025b8f48bd34344e2987eba3757f966c.zip
package-infra: limit the number of // jobs
The current code spawns as many jobs as up to twice the number of CPUs. On small-class machines like laptops, with a limitted amount of memory, but still a few CPUs (real or hyperthreads), the HDD becomes a bottleneck, and it becomes almost impossible to do anythiong else while there is a build in progress. Limit the number of jobs to the number of CPUs plus one. Even on fast machines with fast HDDs, this settings keeps the machine fully busy (for those packages that can build in parallel, of course). For example, building qemu or the linux kernel kept my hyperthreaded hexa Core i7 with 18GiB of RAM, busy at 99% (I never ever managed to get 100% even with more jobs, not even 200); while on my hyperthreaded dual Core i5 with only 4GiB and a slow HDD, I still topped at 100% CPU, while still able to do some work involving the HDD. If the number of processors is not available, assume one. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Nathan Lynch <ntl@pobox.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Nathan Lynch <ntl@pobox.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Diffstat (limited to 'linux/linux-ext-xenomai.mk')
0 files changed, 0 insertions, 0 deletions