public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: Christophe Lyon <>
Cc:, Szabolcs Nagy <>,
	Luis Machado <>
Subject: Re: Arm GDB buildbot workers
Date: Fri, 8 Jul 2022 12:46:53 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Christophe,

On Fri, Jul 08, 2022 at 12:11:13PM +0200, Christophe Lyon wrote:
> On 7/8/22 01:13, Mark Wielaard wrote:
> > OK. See the attached patch, 4 new workers each connected to a gdb CI
> > builder.
> They are up and running! \o/
> I'll probably stop/start them several time to make adjustments like
> "admin name".

Great. In general that should be fine. It might interrupt a build, but
that should be retried when the worker comes backup.

> > Note that it might be helpful for keeping builds totally separate you
> > can use a worker for multiple builders. Depending on the number of
> I am not sure to follow?
> Why having a worker for multiple builders helps keeping the builds separate?

Sorry, I missed a word... "separate, but you" ...

> My plan was to have 1 container running a single worker/builder.
> That is 4 containers for 4 GDB "configs (distro x target)", 4 containers
> for 4 binutils "configs", X containers for X "configs".
> But since these containers would use the same docker image, I think I'll
> need to adjust the worker_dir in, otherwise for instance GDB
> and binutils containers/workers/builders would share the same dir, which
> won't work (they would compete for the twistd* files etc...)

Yes, each worker needs a separate worker dir. Which they normally have
in a container unless they share a volume. But I believe that is what
you are doing, have a shared bind mounted directory with the host.

You can of course start each container with separate --env WORKERNAME
environment variables, so you can share the image without hardcoding

> Do you instead recommend to have 1 (larger) container per distro x
> target, and run binutils/GDB/GCC builders inside this single container?

That is what I would recommend for a (virtual) machine. I think it
makes some sense for containers too, but maybe having separate
containers each with a dedicated worker/builder is smarter in that

One advantage is that you can more easily control how many builds are
running at the same time. If the buildbot sees e.g. 8 different
workers it thinks they are all independent and it is fine to start 8
builds in parallel. While if you have one worker you can set
max_builds=4 and the buildbot will only start 4 builds at the same
time, queuing others.

On the other hand with separate containers per worker you can more
easily create "small" and "big" workers which handle completely
different builds (e.g. you might want a big dedicated gcc builder that
may use 32 vpcus at once, while for binutils builds you dedicate a
small container that only uses 4 vcpus at a time). We have ncpus vs
maxcpus for that, but it isn't as fine grained.



      reply	other threads:[~2022-07-08 10:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07 13:50 Christophe Lyon
2022-07-07 23:13 ` Mark Wielaard
2022-07-08 10:11   ` Christophe Lyon
2022-07-08 10:46     ` Mark Wielaard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).