All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve MacLean <Steve.MacLean@microsoft.com>
To: Nick Gasson <nick.gasson@arm.com>, Ian Rogers <irogers@google.com>
Cc: Steve MacLean <steve.maclean@linux.microsoft.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>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Stephane Eranian <eranian@google.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [EXTERNAL] Re: [PATCH v4] perf inject --jit: Remove //anon mmap events
Date: Fri, 12 Jun 2020 19:00:13 +0000	[thread overview]
Message-ID: <BN7PR21MB166740321F6EACF49E9BC874F7810@BN7PR21MB1667.namprd21.prod.outlook.com> (raw)
In-Reply-To: <xgl9mu5nyugm.fsf@arm.com>

>>> Hi Ian,
>>>
>>>> I tried this as well with latest perf/core. The difference is that 
>>> unresolved addresses currently look like:
>>>
>>>      0.00%  java             [JIT] tid 221782       [.] 0x0000ffff451499a4
>>>      0.00%  java             [JIT] tid 221782       [.] 0x0000ffff4514f3e8
>>>      0.00%  java             [JIT] tid 221782       [.] 0x0000ffff45149394
>>>
>>> But after Steve's patch this becomes:
>>>
>>>      0.00%  java             [unknown]              [.] 0x0000ffff58557d14
>>>      0.00%  java             [unknown]              [.] 0x0000ffff785c03b4
>>>      0.00%  java             [unknown]              [.] 0x0000ffff58386520
>>>
>>> I couldn't see any events that were symbolised before but are no 
>>> longer symbolised after this patch.
>>
>> I see this, thanks for digging into the explanation! Were you able to 
>> get a test case where the unknowns went down? For example, by forcing 
>> the code cache size to be small? This is the result I'd expect to see.
>
>I tried the same Dacapo benchmark as you with different values of InitialCodeCacheSize and grepped for -e '\[unknown\]' -e '\[JIT\]'.
>
>       Base   Patched
> 100M  338    373
> 50M   333    315
> 25M   323    368
> 15M   1238   309
> 10M   2600   333
> 1M    6035   337
>
>This looks fairly convincing to me: the cliff at 15M is where the code cache starts needing to be enlarged.
>

Removing the anonymous mappings causes a small regression.  Specifically,
the reporting of the module name goes from "[JIT] tid <tid>" to "[unknown]".
This occurs when the JIT fails to report memory used in jitdump before it 
is used.

However there is also confirmation that JAVA does see the reported issue 
when using a small code cache.  The current patch resolves the issue in
this case.

I see two options:

+ Accept the regression. Since this is a regression for a jit dump 
reporting synchronization error, this may be a reasonable option.

+ Design a more complicated patch. Either
    + Only strip parts of // anon mmap events overlapping existing 
      jitted-<pid>-<code_index>.so mmap events.
    + Only strip parts of // anon mmap events overlapping prior
      // anon mmap events

Any opinions?

  reply	other threads:[~2020-06-12 19:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  1:51 [PATCH v4] perf inject --jit: Remove //anon mmap events Steve MacLean
2020-05-27 19:00 ` Ian Rogers
2020-05-27 19:27   ` [EXTERNAL] " Steve MacLean
2020-05-27 20:59     ` Ian Rogers
2020-05-28  9:32       ` Ian Rogers
2020-05-29 18:48         ` Steve MacLean
2020-05-29 21:44           ` Steve MacLean
2020-06-01  6:17         ` Nick Gasson
2020-06-01  8:53           ` Ian Rogers
2020-06-01 10:02             ` Nick Gasson
2020-06-12 19:00               ` Steve MacLean [this message]
2020-06-12 19:33                 ` Ian Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN7PR21MB166740321F6EACF49E9BC874F7810@BN7PR21MB1667.namprd21.prod.outlook.com \
    --to=steve.maclean@microsoft.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nick.gasson@arm.com \
    --cc=peterz@infradead.org \
    --cc=steve.maclean@linux.microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.