[Reproducible-builds] Number of CPUs for armhf builds

Vagrant Cascadian vagrant at debian.org
Mon Mar 7 14:10:44 UTC 2016

On 2016-03-07, Holger Levsen wrote:
> 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.

Sure, but I suspect there are *some* builds that will never succeed in
under 12 hours with a single CPU core (on the current armhf build
hardware, anyways).

>> 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?

Overall I like the proposal to stop varying number of CPUs for armhf.
There's some variation with number of cores simply due to having
dual-core, quad-core and (recently) octa-core systems.  That also means
we have no builds running with only CPUs=1, which I think is a good
thing overall.

live well,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160307/cd4b0ee4/attachment.sig>

More information about the Reproducible-builds mailing list