Hi, 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? cheers, Holger
Description: This is a digitally signed message part.
_______________________________________________ Reproducible-builds mailing list Reproduciblefirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds