This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC [testsuite] Obey --load-average
- From: Jeff Law <law at redhat dot com>
- To: Daniel Santos <daniel dot santos at pobox dot com>, gcc <gcc at gcc dot gnu dot org>, Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, Mike Stump <mikestump at comcast dot net>
- Date: Fri, 1 Sep 2017 16:35:20 -0600
- Subject: Re: RFC [testsuite] Obey --load-average
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3051781DF2
- References: <ee0afe25-c283-9eb5-72af-e54ed818e6d6@pobox.com> <eb696c33-cb21-b447-b3d4-012e4dd04e03@redhat.com> <c5efe9dd-0722-d548-5246-2c9c4b9cacd8@pobox.com>
On 08/06/2017 05:05 PM, Daniel Santos wrote:
> On 08/03/2017 11:45 AM, Jeff Law wrote:
>> On 08/02/2017 11:34 PM, Daniel Santos wrote:
>> So does this perform better than make -j X -l X? I use that with good
>> success.
>>
>> jeff
>
> Sorry for my slow response!
>
> For a short answer, if you have 8 CPU cores and you run make -j8 -l8
> check then everything is fine until cron needs to do something that eats
> 4 CPUs and you end up with a load average of 12. This is because the
> make jobs of the test harness are very long running and make's only
> control lever for regulating load is to not start new jobs until the
> load falls. So if all jobs are already launched, make has no way of
> reducing the load until all tests on that test set have completed.
That's not something I typically see in practice. On my local machine
I'm not usually awake when cron jobs are running, so if the load spikes
due to over-subscription I don't much care :-)
The case that is of most interest to me is the effects on shared servers
and folks that don't consistently use -l to throttle their jobs. Your
patches would probably help in that situation by throttling parallelism
independent of the -l flags.
The second place where your stuff probably helps in a meaningful way is
over-subscription due to parallelism within the gomp testsuite.
I'll leave it to Mike who does most of the review work for the testing
infrastructure these days. I won't objects on any philosophical grounds :-)
Jeff