On Mon, May 30, 2016 at 11:50:00AM +0100, Chris Wilson wrote: > On Mon, May 30, 2016 at 01:44:52PM +0300, Marius Vlad wrote: > > The explanation is the same as in the previous series: the GEM tests are > > taking too long. Either I sack them under nightly runs or decrease the > > runtime. As new tests are added, it will take too long to provide > > meaningful output from BAT. There are platforms that reach the timeout > > (of 15minutes), and the slowest platform is the one that provides the > > runtime for the entire CI system (as we wait and collect the results > > from all of them). > > I am all for improving BAT, dropping tests is not acceptable imo. > Replacing them with equivalent-or-better that run quickly should be the > goal. Otherwise, you get into the same situation with the nightly runs > (that already exclude gem_concurrent_blit despite it being one of the > few tools that catch basic errors in GEM). I'm far from being the expert here to work on improving them, hence my suggestion to tune-down the execution time my first approach. The consensus is to have some sort of work-around in some acceptable time-frame. Improving, on different platforms, is an endeavour on itself. Have another suggestion, similar to Nightly runs. Have an extended namespace for GEM test that take/require a longer runtime and run them before Nightly kicks in. Basically have a shorter run-time for BAT and longer runtime (under that extended name) for extended runs. Atm, I'm timing concurrent_blit on a couple of platforms to see how much time it normally takes. If under a couple of hours that would be acceptable. Hoping that by segregating GEM tests would remove the noise I'm seeing for Nightly runs. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
