Hi folks,
I've got a 4-core machine which I want to use for more than one
buildbot, but I'm not sure how it would behave.
For example, I can see on slaves.py:
create_slave("gribozavr1", properties={'jobs': 8},
max_builds=1),
That slave has three bots:
clang-x86_64-debian-fast, llvm-clang-lld-x86_64-debian-fast,
lldb-x86_64-debian-clang
Does that mean that *any* one of the three can start at any time but
only one can run at a time? So, for example, clang-x86 could run three
times before lldb had the change to trigger? Or would that balance the
executions?
My idea is to have two builds at the same time using half of the
resources (I want low latency, not high bandwidth), so I would:
create_slave("linaro-a15-01", properties={'jobs': 2},
max_builds=2),
Which would allow for two concurrent builds, hopefully the current A15
check and self-hosting bots.
My big question is: would this allow two concurrent "check" builds to
run and no "self-hosting", or would that never/rarely happen?
cheers,
--renato
On Wed, Jul 9, 2014 at 9:58 AM, Renato Golin <renato.golin at linaro.org> wrote:> Hi folks, > > I've got a 4-core machine which I want to use for more than one > buildbot, but I'm not sure how it would behave. > > For example, I can see on slaves.py: > > create_slave("gribozavr1", properties={'jobs': 8}, max_builds=1), > > That slave has three bots: > > clang-x86_64-debian-fast, llvm-clang-lld-x86_64-debian-fast, > lldb-x86_64-debian-clang > > Does that mean that *any* one of the three can start at any time but > only one can run at a time? So, for example, clang-x86 could run three > times before lldb had the change to trigger?I think there is a queue of builds scheduled for a slave. So after a commit three builds are added to the queue, then one of them starts. If a commit comes while the queue is still non-empty, then all those builds are also added to the queue. But then the build ends, and the bot picks the first scheduled build from the queue; instead of executing it at the specified revision, it will coalesce all builds scheduled for that bot and just execute the latest one. I think this is how it works, I could be wrong, though. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
On 9 July 2014 10:28, Dmitri Gribenko <gribozavr at gmail.com> wrote:> But then the build ends, and the > bot picks the first scheduled build from the queue; instead of > executing it at the specified revision, it will coalesce all builds > scheduled for that bot and just execute the latest one.The way this buildbot behaves (http://lab.llvm.org:8011/buildslaves/gribozavr1) seems to corroborate your story, so, in theory, the queue should be deterministic, and iterate round robin between builds. I'll give it a try, thanks! --renato