New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 869843 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 16
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 867827



Sign in to add a comment

Pass Histogram Memory Segments on Command Line

Project Member Reported by bcwh...@chromium.org, Aug 1

Issue description

Currently, the shared memory segments used to hold histograms created by subprocesses is passed as an RPC immediately after the subprocess is launched.

Until that RPC is received, however, any histograms created by the subprocess will not be persistent.  This has not generally been a problem since these processes generally don't do anything until they receive control messages and the first such message is the one that establishes the memory used for histograms.

Mojo messages, however, apparently travel over a different channel and thus can be processed before the RPC message with the memory segment.  Thus, processing starts and histograms get created in non-persistent memory.

Change the passing of the shared memory segment to be done on the command line so it is guaranteed to be engaged before anything else begins work.
 
Blocking: 867827
Any chance this issue could be addressed in M70 please?

For audio service experiment, we are trying to fix all our current issues in M70 in order to do another beta analysis in M70 beta, and if all goes well roll out to stable. So we would need this fix to be sure the group count difference doesn't hide any metrics regression.
I have it as an OKR for Q3 but other things have priority.  I don't think it'll make the M70 branch in 4 weeks.  Possible, but please don't count on it.
I took a quick look at this.  Passing on the command-line is going to be more difficult than I expected because the existing code I was thinking of using is only for a global read-only memory segment that is set once and forever reused.  That's not going to be directly applicable to memory segments that are created individually for each sub-process.

Would it be simpler to just have sub-processes check their IPC queue before doing any Mojo work?
Status: Fixed (was: Assigned)
PersistentMetrics originally was written to pass the shared memory segment to children as soon as the IPC channel was open.  The conversion to Mojo followed this practice.  However, it seems that with Mojo (and perhaps even with older IPC), this isn't necessary: The message can be created immediately and it will be queued internally for delivery as soon as the channel is open.

Sadrul made a change to not wait to create/send the message until the channel opens but rather do it as soon as the process is launched and let Mojo deal with it.

https://chromium-review.googlesource.com/1174709

This should put the creation of the metrics memory as the first message in the queue and fix the problem where other messages were getting queued first and thus metrics created by their execution not being persistent.

bcwhite@, could you clarify (double-checking):

"Until that RPC is received, however, any histograms created by the subprocess will not be persistent" - does it mean that:

(a) any recordings to this histogram during the utility process lifetime won't be persistent in case of this race;

or

(b) only attempts to record the histogram before that RPC fail, and after the RPC the histogram can be recorded successfully?
A.  If a histogram is created before a persistent memory segment is activated, that histogram is forever non-persistent.
Cc: olka@google.com marinaciocea@chromium.org maxmorin@chromium.org

Sign in to add a comment