Re: SPS Profiles are now captured for entire subprocess lifetime

[Benoit Girard]

Thanks Mike for your hard work pushing this through!

In theory it does let us profile e10s on TAlos, but I'm sure well will find
more usability issues. It's unclear if they will be a blocker or not. If
there's outstanding issues I don't think we know about them. Please file
them and CC me on any issues you run into. I want us to continue to make
Talos profiler easier.

Once we've reached a good baseline we can have another look at how to
display 'comparative profiles' and making it easier to highlight
difference. For instance it took us way too long to identify that image
cache was disable on e10s and I'd like to get us to the point where this
type of regression would be trivial from a before/after profile.

On Thu, Dec 3, 2015 at 5:27 PM, Kartikaya Gupta  wrote:

> \o/
>
> Does this get us all the way to "profile talos runs with e10s
> enabled", or are there still pieces missing for that? IIRC this set of
> patches was a prerequisite for being able to do that.
>
> On Thu, Dec 3, 2015 at 4:52 PM, Mike Conley  wrote:
> > Just a heads up that there have been recent developments with regards to
> > gathering SPS profiles from multiple processes.
> >
> > Bug 1103094[1] recently landed in mozilla-central, which makes it so that
> > if a subprocess starts up _after_ profiling has already been started in
> the
> > parent, then the subprocess will start profiling as well using the same
> > features and settings as the parent.
> >
> > Bug 1193838[2], which is still on inbound, will make it so that if we are
> > profiling while a process exits, we will hold onto that profile until the
> > profiles are all requested by the parent process for analysis. Right now
> we
> > hold these "exit profiles" in a circular buffer that's hardcoded at an
> > arbitrary limit of 5 profiles.
> >
> > The upshot is that in many cases, if you start profiling, you'll not lose
> > any profiles for subprocesses that start or finish before you choose to
> > analyze the profiles. \o/
> >
> > Just wanted to point those out. Thanks to BenWa for the reviews! Happy
> > profiling,
> >
> > -Mike
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1103094
> > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1193838
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SPS Profiles are now captured for entire subprocess lifetime

[Mike Conley]

Part of the way. The last bit is to de-duplicate all of the Profiler.js
scripts in talos, and get them to use the asynchronous mechanisms for
profile gathering and writing (since they're currently using
dumpProfileToFile, which prevents us from getting out-of-process profiles).

That'll be in bug 1182595, I think.

Almost there. :)



On 3 December 2015 at 17:27, Kartikaya Gupta  wrote:

> \o/
>
> Does this get us all the way to "profile talos runs with e10s
> enabled", or are there still pieces missing for that? IIRC this set of
> patches was a prerequisite for being able to do that.
>
> On Thu, Dec 3, 2015 at 4:52 PM, Mike Conley  wrote:
> > Just a heads up that there have been recent developments with regards to
> > gathering SPS profiles from multiple processes.
> >
> > Bug 1103094[1] recently landed in mozilla-central, which makes it so that
> > if a subprocess starts up _after_ profiling has already been started in
> the
> > parent, then the subprocess will start profiling as well using the same
> > features and settings as the parent.
> >
> > Bug 1193838[2], which is still on inbound, will make it so that if we are
> > profiling while a process exits, we will hold onto that profile until the
> > profiles are all requested by the parent process for analysis. Right now
> we
> > hold these "exit profiles" in a circular buffer that's hardcoded at an
> > arbitrary limit of 5 profiles.
> >
> > The upshot is that in many cases, if you start profiling, you'll not lose
> > any profiles for subprocesses that start or finish before you choose to
> > analyze the profiles. \o/
> >
> > Just wanted to point those out. Thanks to BenWa for the reviews! Happy
> > profiling,
> >
> > -Mike
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1103094
> > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1193838
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SPS Profiles are now captured for entire subprocess lifetime

[Kartikaya Gupta]

\o/

Does this get us all the way to "profile talos runs with e10s
enabled", or are there still pieces missing for that? IIRC this set of
patches was a prerequisite for being able to do that.

On Thu, Dec 3, 2015 at 4:52 PM, Mike Conley  wrote:
> Just a heads up that there have been recent developments with regards to
> gathering SPS profiles from multiple processes.
>
> Bug 1103094[1] recently landed in mozilla-central, which makes it so that
> if a subprocess starts up _after_ profiling has already been started in the
> parent, then the subprocess will start profiling as well using the same
> features and settings as the parent.
>
> Bug 1193838[2], which is still on inbound, will make it so that if we are
> profiling while a process exits, we will hold onto that profile until the
> profiles are all requested by the parent process for analysis. Right now we
> hold these "exit profiles" in a circular buffer that's hardcoded at an
> arbitrary limit of 5 profiles.
>
> The upshot is that in many cases, if you start profiling, you'll not lose
> any profiles for subprocesses that start or finish before you choose to
> analyze the profiles. \o/
>
> Just wanted to point those out. Thanks to BenWa for the reviews! Happy
> profiling,
>
> -Mike
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1103094
> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1193838
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform