<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 2:39 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 01/10/2020 20:09, Joel Sherrill wrote:<br>
<br>
> What was the rationale behind the choice of the default for the number <br>
> of jobs for the waf build system?<br>
I don't know. It is the default behaviour of waf. I noticed also <br>
scalability problems but had no time to track them down. It could be <br>
also a limitation of the Python multiprocessing capabilities. I am also <br>
not a waf expert, I may have produced some bottlenecks.<br></blockquote><div><br></div><div>I don't think you produced any bottlenecks. Here are a couple of fragments</div><div>from my build. I have attached the ini file so you can double check that it</div><div>does match. Please let me know if the ini matches the configure command</div><div>or not. If it doesn't, then I have a lot of bogus builds. :(</div><div><br> ../rtems/configure --target=arm-rtems6 --enable-rtemsbsp=gumstix --prefix=/home/joel/rtems-cron-6/tools/6/bsp-install --disable-networking --enable-posix --disable-smp --disable-multiprocessing --enable-rtems-debug --enable-profiling --enable-tests --enable-cxx --enable-maintainer-mode<br>+ make -j24<br><br>real 1m53.064s<br>user 7m14.675s<br>sys 1m45.913s<br></div><div>.....</div><div><br></div><div>+ ./waf -j 24<br><br>real 1m1.404s<br>user 0m9.601s<br>sys 0m1.547s<br></div><div><br></div><div>Notice how the build time for waf is 50 seconds faster but that doesn't </div><div>match the user and system time. Perhaps the Python jobs model doesn't</div><div>keep them as children the same way so time doesn't get to count them.</div><div><br></div><div>I honestly can't explain that.</div><div><br></div><div>--joel</div></div></div>