Re: [Reproducible-builds] Number of CPUs for armhf builds
Hi, On Montag, 7. März 2016, Vagrant Cascadian wrote: > 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). I doubt there are many of those, who will manage with dual-cores in 12h, especially if there are other builds going on at the same time. > 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. I've implemented and documented this in the variation table now. cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Number of CPUs for armhf builds
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 signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Number of CPUs for armhf builds
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 signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
