All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=744728

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=98bf40827a083e5daff9ba75809b3321ee27255d7b8f389965af999c1d676bc7


Bot(s) for this bug's original alert(s):

chromium-rel-win7-gpu-intel

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8973799262778114016

=== Auto-CCing suspected CL author hajimehoshi@chromium.org ===

Hi hajimehoshi@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Hajime Hoshi
  Commit : 5d64433a4a096a86544cd6d80f0a18ef066396ce
  Date   : Thu Jul 13 14:50:22 2017
  Subject: Add SharedMemory::mapped_id()

Bisect Details
  Configuration: winx64intel_perf_bisect
  Benchmark    : media.tough_video_cases_tbmv2
  Metric       : memory:chrome:browser_process:reported_by_chrome:effective_size_avg/video.html?src_crowd1080_vp9.webm_seek
  Change       : 28.88% | 35328924.77 -> 45532434.8333

Revision             Result                   N
chromium@486354      35328925 +- 6018172      6      good
chromium@486365      36469214 +- 296902       6      good
chromium@486370      36426146 +- 47615.7      6      good
chromium@486373      35243034 +- 6485715      6      good
chromium@486374      35391549 +- 6025331      6      good
chromium@486375      45389452 +- 5974927      6      bad       <--
chromium@486395      45517639 +- 6122337      6      bad
chromium@486435      45532435 +- 6157942      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.crowd1080.vp9.webm.seek media.tough_video_cases_tbmv2

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8973799262778114016


For feedback, file a bug with component Speed>Bisection

 Issue 744737  has been merged into this issue.

Hmm, actually this seems the case since my CL adds a member UnguessableToken to SharedMemory.

On second thought, as UnguessableToken is 16 bytes, I don't think this increased memory usage in 10 MiB.

+tasak

https://chromeperf.appspot.com/report?sid=8cb54ebafc583993ac9241ed7260741a84db22b747468f48f422b965560f379b

Actually shared memrory's effective size is affected. My CL https://chromium-review.googlesource.com/c/566353/ should be related to this issue. However, that CL doesn't increase (or decrease) the number of SharedMemory tracked by SharedMemoryTracker. That CL just changes the memory allocator dump's IDs.

I am not sure where the number 'shared_memory:effecitve_size_avg' comes from in the above figures. primiano@, do you have any suggestions?

> I am not sure where the number 'shared_memory:effecitve_size_avg' comes from in the above figures. primiano@, do you have any suggestions?

Opening the trace is the best way to answer that. If there are no edges it comes from the sum of shared_memory.size. If there are edges it comes from SUM(shared_memory.size) - SUM(size of incoming edges)

My suggestions is to open the traces before and after and eye ball where the difference comes from. You can use the "Trace" link from the waterfall.
E.g,:

before: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_21-2017-07-13_07-18-23-15170.html
after: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_21-2017-07-13_12-46-19-3022.html

primiano@: Aha, that is a great help, Thank you! (BTW, how did you find these trace results?)

I guess this is an expected behavior.

Before the CL, some SharedMemory in browser process couldn't have IDs. SharedMemoryTracker user their addresses instead of IDs in such cases, thus ownership edges and effective-size-calculation are not accurate. This is a known problem.

After the CL, all SharedMemory have IDs and effective size calculation is now correct.

Actually, in the former trace, we can find that there are three big SharedMemory dumps over 8000 [KiB] in browser process that don't have IDs, and those effective sizes are about 1000 [KiB]. In the latter trace, it looks like they have IDs (and correct ownership edges), and their effective sizes are about 4000 [KiB], thus the difference is about 9 [MiB].

So, I'd like to mark this issue as wont-fix.

> After the CL, all SharedMemory have IDs and effective size calculation is now correct.

To be exact, the ownership edges are not completely accurate and we plan to fix this by shipping https://chromium-review.googlesource.com/c/557741/.

 Issue 745925  has been merged into this issue.

 Issue 745937  has been merged into this issue.

 Issue 745903  has been merged into this issue.