Re: [Intel-gfx] [PATCH] drm/i915/mst: fix pipe and vblank enable

[Jani Nikula <jani.nikula@intel.com>]

On Fri, 14 Feb 2020, "Sarvela, Tomi P" <tomi.p.sarvela@intel.com> wrote:
>> From: Jani Nikula <jani.nikula@intel.com>
>> 
>> On Mon, 10 Feb 2020, Arkadiusz Hiler <arkadiusz.hiler@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