Probe/process restrictions

Benjamin Smedberg benjamin at smedbergs.us
Thu Jan 26 16:35:32 UTC 2017


That should be ok. We need to make sure that nothing is ever just "content"
though: until we enable e10s at 100% everything needs to be content+main.

--BDS

On Thu, Jan 26, 2017 at 8:53 AM, Georg Fritzsche <gfritzsche at mozilla.com>
wrote:

> With histograms we (currently) record & send them on every process, no
> matter whether we are interested in it.
> E.g. we will for now record everything in the GPU process as well (once
> active), even if no-one ever looks at it.
> It's hard to step back from collecting this data later, due to having
> reach out to teams.
>
> So the idea was that we start with requiring choices and see how this
> works out.
> Is making the process choice mandatory & explicit with choices like "all",
> "main", "content", "all childs", ... sufficient to address the foot-gun
> issue?
>
> Georg
>
> On Wed, Jan 25, 2017 at 7:52 PM, Benjamin Smedberg <benjamin at smedbergs.us>
> wrote:
>
>> Even with the mandatory process listing, I'm concerned that anything that
>> may be recorded in a content process must also be able to be recorded in
>> the main process for the non-e10s config. So we need to make sure during
>> reviews or programmatically that everything listed for content recording is
>> also allowed in chrome.
>>
>> --BDS
>>
>> On Wed, Jan 25, 2017 at 8:44 AM, Alessio Placitelli <
>> aplacitelli at mozilla.com> wrote:
>>
>>> The rationale behind that choice can be found here in bug 1278556 [1],
>>> comments 1 & 3.
>>>
>>> Quoting Chris (partially, see the bug for the extended explaination):
>>> "It would be nice to force people to identify from which process they want
>>> data collected. On the client and server we could then have some validation
>>> and omission of invalid-process data, and multi-process analyses wouldn't
>>> need to be clever to avoid the 400 data points present on the "wrong"
>>> process."
>>>
>>> The rule currently applies only to Scalars, but it will eventually
>>> extend to histograms too (there are currently no short term plans, though).
>>>
>>> When using the JS API and trying to change a scalar from the wrong
>>> process, a warning is printed to the browser console (no exception is
>>> thrown). In bug 1324774, we will make sure that such warnings trigger
>>> failures on automation as well.
>>>
>>> I think that the problem with bug 1325536 is that there was a bug in the
>>> Scalar C++ API that didn't enforce this behaviour, and that's the reason
>>> why the problem wasn't discovered earlier. Bug 1333024 fixed that and
>>> landed shortly after.
>>>
>>>
>>> [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=1278556#c1
>>>
>>> 2017-01-25 14:22 GMT+01:00 Benjamin Smedberg <benjamin at smedbergs.us>:
>>>
>>>> Quoting Alessio in bug 1325536:
>>>>
>>>> "Are these measurements collected on the main process or on a different
>>>> process?
>>>> If no 'record_in_processes' property is specify, the measure is assumed
>>>> to be
>>>> collected on the main process: collection on other processes is
>>>> discarded."
>>>>
>>>> Can somebody explain the rationale for this behavior? This seems like a
>>>> pretty big footgun for people adding new metrics. Does this rule apply only
>>>> to scalars or also to histograms?
>>>>
>>>> I'd like to counter-propose that by default we assume that probes can
>>>> happen in any process. If that's not practical for some reason, I think we
>>>> should at a minumum add debug asserts if people try to record a
>>>> main-process-only metric from another process type.
>>>>
>>>> --BDS
>>>>
>>>> _______________________________________________
>>>> fhr-dev mailing list
>>>> fhr-dev at mozilla.org
>>>> https://mail.mozilla.org/listinfo/fhr-dev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> fhr-dev mailing list
>> fhr-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/fhr-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fhr-dev/attachments/20170126/a517a692/attachment.html>


More information about the fhr-dev mailing list