We should merge this with ChildProcessHostImpl::ChildProcessUniqueIdToTracingProcessId() https://cs.chromium.org/chromium/src/content/common/child_process_host_impl.h?type=cs&q=childprocesshostimpl&sq=package:chromium&l=62

We are going to need this for the window-server too. So let's prioritize this.

I think we should have unique tracing id for processes in mustash. So we can trace memory allocated by mus and gpu processes but assigned to other processes.

chiniforooshan, I think you are working on tracing, could you please take over?

The implementation of ClientProcessUniqueIdToTracingProcessId in the current code itself is wrong:
The id must be obtained from hash of pid that is given by ChildProcessHostImpl::ChildProcessUniqueIdToTracingProcessId.
The child process uses this id here
https://chromium.googlesource.com/chromium/src/+/master/content/browser/tracing/trace_message_filter.cc#18
to match the segments.
So, currently tracing is broken because there are two functions that give different hashing.

Okay sorry, this issue is bigger than just issue since it includes creating tracing pid for new processes. I am reversing the merge.

 Issue 679755  has been merged into this issue.

I do not think this would be required anymore after https://codereview.chromium.org/2535213002. But in case this is required I will get back to this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/efed310cc305f0d89f9d1aa49fb5e0d4ec9ff2cd

commit efed310cc305f0d89f9d1aa49fb5e0d4ec9ff2cd
Author: ssid <ssid@chromium.org>
Date: Tue Feb 07 05:29:58 2017

[memory-infra] Make client discardable segments non-weak

The discardable segments shared between the processes do not add the
same global dump ids since the process id of the client is not available
in the manager. Temporarily we do not create weak dumps since the dump
provider is broken.

BUG=661257,  687399 

Review-Url: https://codereview.chromium.org/2668193002
Cr-Commit-Position: refs/heads/master@{#448554}

[modify] https://crrev.com/efed310cc305f0d89f9d1aa49fb5e0d4ec9ff2cd/components/discardable_memory/common/discardable_shared_memory_heap.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef3010cf1291da1c3eb9bbdd6ebd82c6d65f675c

commit ef3010cf1291da1c3eb9bbdd6ebd82c6d65f675c
Author: ssid <ssid@chromium.org>
Date: Mon Feb 27 15:41:03 2017

[memory-infra] Update discardable memory dump provider names for background whitelist

BUG=661257

Review-Url: https://codereview.chromium.org/2712703004
Cr-Commit-Position: refs/heads/master@{#453219}

[modify] https://crrev.com/ef3010cf1291da1c3eb9bbdd6ebd82c6d65f675c/base/trace_event/memory_infra_background_whitelist.cc

Sorry, I think this one is waiting on https://bugs.chromium.org/p/chromium/issues/detail?id=604726 so that we will have right edges between the discardable shared memory dumps.
I will make a plan for this issue by next week.

ping: any updates in the last week or so?

I'm not sure about this issue, but now is  crbug.com/604726  really a blocker? The rest tasks for that is only to enable the new ownership edges.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6dcb76a5840359dd7617e57c020c08cc3a09c297

commit 6dcb76a5840359dd7617e57c020c08cc3a09c297
Author: Siddhartha <ssid@chromium.org>
Date: Thu Aug 10 22:25:47 2017

memory-infra: Change discardable memory dump provider to use shared memory edges

The discardable memory dump provider uses SharedMemory and should be
using the edges created by the new SharedMemoryTracker.

Bug: 661257
Change-Id: Ie20395d7696089c74ab5bdce0e6b09d66e564805
Reviewed-on: https://chromium-review.googlesource.com/607088
Reviewed-by: Hajime Hoshi <hajimehoshi@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Commit-Queue: Siddhartha S <ssid@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493566}
[modify] https://crrev.com/6dcb76a5840359dd7617e57c020c08cc3a09c297/base/memory/discardable_shared_memory.h
[modify] https://crrev.com/6dcb76a5840359dd7617e57c020c08cc3a09c297/components/discardable_memory/common/discardable_shared_memory_heap.cc
[modify] https://crrev.com/6dcb76a5840359dd7617e57c020c08cc3a09c297/components/discardable_memory/service/discardable_shared_memory_manager.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb

commit e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb
Author: Siddhartha <ssid@chromium.org>
Date: Fri Aug 18 23:11:02 2017

Memory-infra: Remove use of unique tracing ID and add resident size to discardable dumps

This CL does:
1. Remove the use of tracing process ID and unique client ID in
   discardable service since we switched to shared memory ownership
   edges,  crbug.com/604726 .
2. Use the resident size calculated by the shared memory dumps in the
   discardable segment instead of calculating again. This means the
   discardable providers will account for the wasted memory due to
   fragmentation.
3. Moves all the edge logic to DiscardableSharedMemory since it knows
   about |SharedMemory| and code is shared by manager and client.

Note to perf sheriffs: This might cause perf regression or improvements
in discardable memory total since it accounts for the resident size
instead of allocated size.

Bug: 661257
Change-Id: Ia88b90399237d81ff4e2410ae4712157e852ca9e
Reviewed-on: https://chromium-review.googlesource.com/609441
Commit-Queue: Siddhartha S <ssid@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495732}
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/memory/discardable_shared_memory.cc
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/memory/discardable_shared_memory.h
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/memory/discardable_shared_memory_unittest.cc
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/memory/shared_memory_tracker.cc
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/memory/shared_memory_tracker.h
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/trace_event/memory_allocator_dump.h
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/trace_event/process_memory_dump.cc
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/base/trace_event/process_memory_dump_unittest.cc
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/components/discardable_memory/common/discardable_shared_memory_heap.cc
[modify] https://crrev.com/e241d0ac5772386e8b7e8016c99c0ac5d07e8dcb/components/discardable_memory/service/discardable_shared_memory_manager.cc

This bug has an owner, thus, it's been triaged. Changing status to "assigned".