Lower event-tracing log-thread priority.

Lower event-tracing log-thread priority.

Lowers risk of the event-tracing thread affecting measurements (and
performance of device). Entirely speculative, but shouldn't hurt.
Timings are still done on the thread that calls the trace macros.

BUG=
R=tommi@webrtc.org

Committed: https://crrev.com/0ec9a9b9fc6df69a1deb3c9a4865c5b85132df3a
Cr-Commit-Position: refs/heads/master@{#12943}

[pbos-webrtc, 2016-05-27 06:51:26]

PTAL, this shouldn't interfere with anything, so it'd be best if it doesn't
contend either.

[tommi, 2016-05-27 07:59:02]

how will you follow up on this?

[pbos-webrtc, 2016-05-27 08:01:47]

On 2016/05/27 07:59:02, tommi-webrtc wrote:
> how will you follow up on this?

Wasn't planning on doing anything specifically? Idea is that this is a
background thread that shouldn't be contending with regular interactions,
encoding or UI so that we measure the correct timings as well as possible, on
platforms where lowering thread priority happens to work.

[tommi, 2016-05-27 08:33:02]

On 2016/05/27 08:01:47, pbos-webrtc wrote:
> On 2016/05/27 07:59:02, tommi-webrtc wrote:
> > how will you follow up on this?
> 
> Wasn't planning on doing anything specifically? Idea is that this is a
> background thread that shouldn't be contending with regular interactions,
> encoding or UI so that we measure the correct timings as well as possible, on
> platforms where lowering thread priority happens to work.

Is it possible that this could cause us to miss events if they're pending in a
queue when a process is being shut down (and the process or thread is simply
terminated).

[pbos-webrtc, 2016-05-27 08:36:12]

On 2016/05/27 08:33:02, tommi-webrtc wrote:
> On 2016/05/27 08:01:47, pbos-webrtc wrote:
> > On 2016/05/27 07:59:02, tommi-webrtc wrote:
> > > how will you follow up on this?
> > 
> > Wasn't planning on doing anything specifically? Idea is that this is a
> > background thread that shouldn't be contending with regular interactions,
> > encoding or UI so that we measure the correct timings as well as possible,
on
> > platforms where lowering thread priority happens to work.
> 
> Is it possible that this could cause us to miss events if they're pending in a
> queue when a process is being shut down (and the process or thread is simply
> terminated).

Nope, it'd cause us to write to log less frequently but nothing ever gets
dropped here. Theoretically we might stall longer on Stop if this causes us to
have more outstanding events, but that's theoretically and only if this thread
gets really-really-really starved.

[tommi, 2016-05-27 08:53:42]

On 2016/05/27 08:36:12, pbos-webrtc wrote:
> On 2016/05/27 08:33:02, tommi-webrtc wrote:
> > On 2016/05/27 08:01:47, pbos-webrtc wrote:
> > > On 2016/05/27 07:59:02, tommi-webrtc wrote:
> > > > how will you follow up on this?
> > > 
> > > Wasn't planning on doing anything specifically? Idea is that this is a
> > > background thread that shouldn't be contending with regular interactions,
> > > encoding or UI so that we measure the correct timings as well as possible,
> on
> > > platforms where lowering thread priority happens to work.
> > 
> > Is it possible that this could cause us to miss events if they're pending in
a
> > queue when a process is being shut down (and the process or thread is simply
> > terminated).
> 
> Nope, it'd cause us to write to log less frequently but nothing ever gets
> dropped here. Theoretically we might stall longer on Stop if this causes us to
> have more outstanding events, but that's theoretically and only if this thread
> gets really-really-really starved.

ok, sgtm, lgtm

[pbos-webrtc, 2016-05-27 09:11:56]

Description was changed from

==========
Lower event-tracing log-thread priority.

Lowers risk of the event-tracing thread affecting measurements (and
performance of device). Entirely speculative, but shouldn't hurt.
Timings are still done on the thread that calls the trace macros.

BUG=
R=tommi@webrtc.org
==========

to

==========
Lower event-tracing log-thread priority.

Lowers risk of the event-tracing thread affecting measurements (and
performance of device). Entirely speculative, but shouldn't hurt.
Timings are still done on the thread that calls the trace macros.

BUG=
R=tommi@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/0ec9a9b9fc6df69a1deb3c9a4...
==========

[pbos-webrtc, 2016-05-27 09:11:58]

Committed patchset #1 (id:1) manually as
0ec9a9b9fc6df69a1deb3c9a4865c5b85132df3a (presubmit successful).

[commit-bot: I haz the power, 2016-05-27 09:11:59]

Description was changed from

==========
Lower event-tracing log-thread priority.

Lowers risk of the event-tracing thread affecting measurements (and
performance of device). Entirely speculative, but shouldn't hurt.
Timings are still done on the thread that calls the trace macros.

BUG=
R=tommi@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/0ec9a9b9fc6df69a1deb3c9a4...
==========

to

==========
Lower event-tracing log-thread priority.

Lowers risk of the event-tracing thread affecting measurements (and
performance of device). Entirely speculative, but shouldn't hurt.
Timings are still done on the thread that calls the trace macros.

BUG=
R=tommi@webrtc.org

Committed: https://crrev.com/0ec9a9b9fc6df69a1deb3c9a4865c5b85132df3a
Cr-Commit-Position: refs/heads/master@{#12943}
==========