Ryan Harper wrote:
I took a slightly different approach. The kvm_tests.cfg file already provides a dependency relationship between different tests. I modified the main loop in the control file to walk the entire list of jobs and pull out any jobs that don't have any dependencies (ie, install tests). And then run N jobs in parallel from that list until it is exhausted; then store the results. Then loop the over the remaining list of jobs again finding the jobs that can be run. On a larger multi core system, one might set the number of parallel jobs equal to the number of cores. I think this works well with using autoserv to farm out different kvm_tests.cfg to different machines.
This is my preference as well, though I think scheduling needs to be cleverer. Each test should specify how much memory and how many cores (the -m and -smp parameters) it needs, and the scheduler needs to make sure we don't over commit the host for tests.
This ensures the best utilization while not interfering with test timing. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
