On Fri, 14 Feb 2020, "Sarvela, Tomi P" <tomi.p.sarv...@intel.com> wrote: >> From: Jani Nikula <jani.nik...@intel.com> >> >> On Mon, 10 Feb 2020, Arkadiusz Hiler <arkadiusz.hi...@intel.com> wrote: >> > As of the 3 days worth of queued shards: >> > >> > I agree that this is unacceptable, but we can do only so much from the >> > CI/infra side. The time has been creeping up steadily over the last year >> > or so and the machines are not getting any faster. >> >> I am *not* trying to say that it's all your fault and you need to >> provide all results faster for the ever-increasing firehose of incoming >> patches. >> >> I'd like to pose the question, what would all this look like if we made >> it a hard requirement that we need a go/no-go decision on every patch >> series within 24 hours? I emphasize that I don't mean full results in 24 >> hours. Given all the other constraints, how could we provide as much >> useful information as possible within 24 hours to make a decision? >> >> In another thread I said, we've shifted a bit from review being the >> bottle neck to shard runs being the bottle neck. It's still much more >> likely that a patch will change due to review feedback instead of shard >> run results. Half a dozen rounds of review ping pong directly leads to >> half a dozen rounds of mostly unnecessary testing. I would not outright >> dismiss only running full igt on reviewed/acked patches. > > This is actually a good idea. In practice, the shards are swamped by the > amount of builds today, and the throughput has been close to 1/h a long > time, even with work ongoing to prune or tighten stupidest IGT tests. > > We could make the shard run requirements stricter: in addition to passing > BAT it would need some amount of Acks. Patchwork already collects them.
Of course, patchwork isn't accurate in picking acks/reviews, but I don't think it has to be. Err on the side of testing, and provide a way to start shard runs manually, also because sometimes you do want the results ASAP on v1. (On that note, would be nice if people could *remove* their patch series from the shard queueu too.) > Another idea has been moving the serialized shard run queue to something > that can handle reordering: trybots can be moved after everything else. This > doesn't affect to the shard queue length though, if we still want to test > everything. Next we'll be figuring out a fair scheduler that does not starve the trybot queue. ;) >> Additionally, there are smaller optimizations to be made (obviously all >> depending on developer bandwidth to implement this stuff), such as >> identifying patches that don't change the resulting binary >> (comment/documentation/whitespace changes), and only running build >> testing on them. > > This idea has been floating around, and would help in 5% changes or so > (which is still noticeable: 1-2 more builds / day tested instead of queued). > > Just need a good diff checker that says "text changes only, skip it". It's probably not as trivial as it initially sounds, but gut feeling says that it's also not a problem that nobody has tried to solve before. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
