tree 0e3bcc56c9687d1450d46a80d6bff7cb0229aa7c
parent 83fcec06209d96134d888137223ef6c5842ea385
author Daniel Dunbar <daniel_dunbar@apple.com> 1494444456 -0700
committer Daniel Dunbar <daniel_dunbar@apple.com> 1494444456 -0700

[BuildSystem] Don't overcommit CPUs in execution queue.

I would like to do a rigorous study of this eventually, but for now the
following logic suggests we should default to numLanes == numCPUs:

1. We should *always* be willing to max out the CPU count if we have enough
   work. As currently implemented, this means we must have numLanes >= numCPUs
   (since we always block a lane once a subprocess is executing).

2. There will always be cache contention from having an overly loaded CPU ready
   set. If we overcommit the CPUs, we are forcing the OS to deal with this load
   in an unblocked build. The benefit we get from that is that the overcommitted
   CPU can mean we recapture latency when one lane has no work.

3. However, we also have to worry about the Core engine which is executing
   outside of the lanes. It is critical that it isn't starved, in order to
   ensure the execution queue is as deep as possible. By overcommitting, we are
   starving the ready queue potentially increasing task latency (the only thing
   we were potentially gaining).

<rdar://problem/32114117> Don't overcommit CPUs in llbuild execution lanes