This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Limit perf data buffer during profiling
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: gcc-patches at gcc dot gnu dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Thu, 18 May 2017 04:35:05 -0400
- Subject: Re: [PATCH] Limit perf data buffer during profiling
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aldyh at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0810D4ACB6
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0810D4ACB6
- References: <20170512093836.19942-1-andi@firstfloor.org>
- Reply-to: aldyh at redhat dot com
Andi Kleen <andi@firstfloor.org> writes:
> From: Andi Kleen <ak@linux.intel.com>
>
> With high -j parallelism the autofdo tests can randomly fail.
> autofdo uses Linux perf to record profiling data.
> Linux perf uses a locked perf buffer. By default it has
> around 516k buffer per uid (/proc/sys/kernel/perf_event_mlock_kb).
>
> An individual perf record tries to grab the full 516k,
> which makes parallel perf record fail.
>
> This patch limits the perf buffer for individual perf record to 8k.
> With the default settings this allows a parallelism of the test
> cases of 16, which is hopefully good enough
So for -jN > 16 it would silently fail again?
I think we should warn when the -jN is sufficiently large such that
tests will randomly fail, and perhaps suggest workarounds with
ulimit/etc.
Aldy