[Reproducible-builds] Number of CPUs for armhf builds
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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 818 bytes
Desc: not available
More information about the Reproducible-builds