Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 11 Nov 2019 12:33:11 +0100
From:   Jiri Olsa <jolsa@redhat.com>
To:     Steve MacLean <Steve.MacLean@microsoft.com>
Cc:     Steve MacLean <steve.maclean@linux.microsoft.com>,
        Stephane Eranian <eranian@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Namhyung Kim <namhyung@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] perf inject --jit: Remove //anon mmap events
Message-ID: <20191111113311.GA9791@krava>
References: <1572553836-32361-1-git-send-email-steve.maclean@linux.microsoft.com>
 <20191101082740.GB2172@krava>
 <CY4PR21MB063262D81AB2BE5FEE88057EF77A0@CY4PR21MB0632.namprd21.prod.outlook.com>
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB063262D81AB2BE5FEE88057EF77A0@CY4PR21MB0632.namprd21.prod.outlook.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Nov 09, 2019 at 04:49:25PM +0000, Steve MacLean wrote:
> > > While a JIT is jitting code it will eventually need to commit more=20
> > > pages and change these pages to executable permissions.
> > >=20
> > > Typically the JIT will want these colocated to minimize branch displa=
cements.
> > >=20
> > > The kernel will coalesce these anonymous mapping with identical=20
> > > permissions before sending an MMAP event for the new pages. This mean=
s=20
> > > the mmap event for the new pages will include the older pages.
> > >=20
> > > These anonymous mmap events will obscure the jitdump injected pseudo =
events.
> > > This means that the jitdump generated symbols, machine code, debuggin=
g=20
> > > info, and unwind info will no longer be used.
> > >=20
> > > Observations:
> > >=20
> > > When a process emits a jit dump marker and a jitdump file, the=20
> > > perf-xxx.map file represents inferior information which has been=20
> > > superceded by the jitdump jit-xxx.dump file.
> > >=20
> > > Further the '//anon*' mmap events are only required for the legacy=20
> > > perf-xxx.map mapping.
> > >=20
> > > When attaching to an existing process, the synthetic anon map events=
=20
> > > are given a time stamp of -1. These should not obscure the jitdump=20
> > > events which have an actual time.
> > >=20
> > > Summary:
> > >=20
> > > Use thread->priv to store whether a jitdump file has been processed
> >=20
> > I'm ok wih the implementation but not sure about the described JIT/mmap=
 logic, Stephane?
> >=20
> > jirka
>=20
> The kernel only seems to coalesce the anonymous mappings when the allocat=
ions grow beyond 64K. It may not affect JITs for smaller sets of JITted cod=
e.  I would guess a javascript JIT engine might not hit this type of proble=
m often.
>=20
> @Stephane Eranian could you comment.
>=20
> @Jiri Olsa I am happy to expand the explanation if it would be helpful.

that'd be great, thanks

jirka