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.
On Thu, Jan 26, 2017 at 8:53 AM, Georg Fritzsche <gfritzsche at mozilla.com>
> 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
> On Wed, Jan 25, 2017 at 7:52 PM, Benjamin Smedberg <benjamin at smedbergs.us>
>> 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.
>> 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 ,
>>> 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"
>>> 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.
>>>  - 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
>>>> If no 'record_in_processes' property is specify, the measure is assumed
>>>> to be
>>>> collected on the main process: collection on other processes is
>>>> 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.
>>>> fhr-dev mailing list
>>>> fhr-dev at mozilla.org
>> fhr-dev mailing list
>> fhr-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fhr-dev