On 06/17/2011 08:21 PM, Darren Hart wrote: > > > On 06/17/2011 08:16 PM, Joshua Lock wrote: >> It's been suggested that BB_NUMBER_THREADS should be 2 * the number of cores >> and PARALLEL_MAKE should be equal to the number of cores available on the >> build machine. >> >> Update local.conf.sample to suggest this. >> >> Signed-off-by: Joshua Lock >> --- >> meta-yocto/conf/local.conf.sample | 4 +++- >> 1 files changed, 3 insertions(+), 1 deletions(-) >> >> diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample >> index ea32b81..43d06e6 100644 >> --- a/meta-yocto/conf/local.conf.sample >> +++ b/meta-yocto/conf/local.conf.sample >> @@ -9,7 +9,9 @@ CONF_VERSION = "1" >> #SSTATE_DIR ?= "${TOPDIR}/sstate-cache" >> >> # Uncomment and set to allow bitbake to execute multiple tasks at once. >> -# For a quadcore, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would >> +# Recommended values are twice the number of processor cores for >> +# BB_NUMBER_THREADS and the number of processor cores for PARALLEL_MAKE >> +# For a quadcore, BB_NUMBER_THREADS = "8", PARALLEL_MAKE = "-j 4" would > > Hrm, where is this coming from? In my experience it works better the > other way around. We probably also need to be explicit about cores > versus threads. OK, let's get some real number behind this. I'm running the attached script on a quadcore (8 thread) i7 system with 8 GB of RAM. an SSD for the OS, and a single spinning disk for the build. We'll see how things look in... 13 2 ^ 2 * 24 / ... 14.08 days ... assuming I don't burn something up first.... maybe I should have programmed in a sleep? nah, that's what the "rm -rf tmp" is for ;-) Would be nice to have some runtime atsar disk, sched, fault stats as well... >> # be appropriate. >> # BB_NUMBER_THREADS = "4" >> # Also, make can be passed flags so it run parallel threads e.g.: > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel