From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [OSSTEST PATCH 2/2] Testing cpupools: recipe for it and job definition Date: Fri, 19 Dec 2014 11:02:04 +0000 Message-ID: <1418986924.20028.34.camel@citrix.com> References: <20141218130919.29909.13566.stgit@Abyss.station> <20141218133902.29909.99057.stgit@Abyss.station> <5492EBFC.8010005@suse.com> <20141218150409.GA2870@zion.uk.xensource.com> <5492EE60.5090005@suse.com> <1418923754.10854.25.camel@Abyss.station> <1418982526.20028.2.camel@citrix.com> <1418986256.10854.30.camel@Abyss.station> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1418986256.10854.30.camel@Abyss.station> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Juergen Gross , George Dunlap , Wei Liu , Ian Jackson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, 2014-12-19 at 11:50 +0100, Dario Faggioli wrote: > > > However, that seems to be taken into account by the fact that, in > > > make-flight, in test_matrix_do_one(), after only 2 jobs are created (the > > > basic debian one and a libvirt one) we have this: > > > > > > # No further arm tests at the moment > > > if [ $dom0arch = armhf ]; then > > > return > > > fi > > > > > > So, yes, I guess I can get rid of such filters in my new function, so > > > that, when ARM maintainers will disable the safety catch above, a job > > > will actually be generated. > > > > We should probably move some of the tests from below the cut to above > > already, e.g. do_sedf_tests and do_credit2_tests aren't arch specific, > > so should be run on arm. > > > I see. Great. :-) > > Scheduler testing being below the cutoff was exactly what made me > thinking that we only wanted basic ARM testing for now, given the > limited HW resources, and to keep the "noise" low Actually if anything we are underutilising the ARM resources we have, they usually finish way in advance of all the x86 stuff. Ian.