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.
Understandable... >> 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, vagrant
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducibleemail@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds