[Reproducible-builds] Number of CPUs for armhf builds

Holger Levsen holger at layer-acht.org
Mon Mar 7 13:53:01 UTC 2016


On Sonntag, 6. März 2016, Vagrant Cascadian wrote:
> > I'm also pondering to change it to use CPUs+1 for the first builds and
> > CPUs for the 2nd ones.
> That would be interesting, although I was thinking we might want to do a
> fewer number of CPUs on the first build, to make it more likely the
> second build doesn't timeout.

I don't think we should make any build slower by design.
> e.g. If your first build is with 4 CPUs (from one of the quad-cores),
> and your second builds with 1 CPU (a dual-core), you're more likely to
> reach the timeout limit on the second build...

you cannot assume such things. Builds are scheduled on arbitrary hosts.

> So combining the two ideas, I guess I would propose CPUs for first
> build, and CPUs+1 for the second build?

I'm not sure, this is what I have been meaning to do, but then I fear that 
CPUs+1 might _slow down_ things if the machine is overloaded already… So I'm 
now pondering to just use the number of cores always, and

- on amd64+i386: make sure by node "hw" design, that every build has a 
different number of cores (either 16 or 17)
- on armhf: stop systematically varying numbers of CPUs, often they will vary 
anyway (by scheduling choices) and then… there's not much unreproducibility 
due to this issue anyway, and we will still notice if there is, on x86 and 
sometimes here too. (And flipping status is actually even more noticable.)

What do you think? Or should I go with CPUs+1 on armhf?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160307/f11a6e7e/attachment.sig>

More information about the Reproducible-builds mailing list