1690626 - mdns_service thread should be registered with the profiler

Status: RESOLVED FIXED

(Core :: WebRTC, task)

Description

[Florian Quèze [:florian]]

I wanted to profile the mdns_service thread to understand why it's continuously using 2 to 3% of a CPU core on my machine, but it looks like it's not registered with the Gecko Profiler.

Comment 1

[Paul Adenot (:padenot)]

Dan, I know it's probably not the best time to ask you to do yet another thing, but do you know whether there is a callback on thread creation, or if we should just call the profiler API directly (bug 1690624 should help).

Are we upstream on this, if no, where is upstream ?

Comment 2

[Dan Minor [:dminor]]

This is all my/our code, so I guess I'll apologize in advance for any problems you find. I think hooking into the profiler API directly would probably be the way to go.

My intention was to use timeouts on the socket reads and writes to idle the thread, so this might be fixable with some tuning of those values.

The other problem here is that once started, this runs until shutdown, even if it is no longer necessary. Depending on the network, there might be background mDNS traffic that we waste time parsing. I filed Bug 1569955 to look into shutting things down if there are no hostnames registered with the service.

Comment 3

[Dan Minor [:dminor]]

Also, a big part of the reason why we're running this service is lack of mDNS support on older versions of Windows, in particular Windows 7. So we might be able to toss a lot of this code and rely upon the OS more once we stop supporting Windows 7. Or, start switching over now on platforms where it is well supported, like OS X and Linux. At the time, I was hesitant to have different code paths for different OSs since this introduced a lot of new code all at once, but that isn't the same concern now.

Comment 4

[Florian Quèze [:florian]]

I looked at this again because I noticed the activity monitor showed the Firefox parent process having between 700 and 1200 idle wake-ups, and it seemed to match with when about:processes was showing the mdns_service thread as using a few percent of CPU.

With the new profiler Rust API it is now straightforward to register the thread with the profiler, and I added a marker to see when there's activity: https://share.firefox.dev/34cXPnt

It looks like handle_mdns_socket is called about every millisecond, so it's actually the cause of the idle wakeups reported by the activity monitor.

(In reply to Dan Minor [:dminor] from comment #2)

The other problem here is that once started, this runs until shutdown, even if it is no longer necessary. Depending on the network, there might be background mDNS traffic that we waste time parsing. I filed Bug 1569955 to look into shutting things down if there are no hostnames registered with the service.

In my experience, the activity in mdns_service seems to stop when the content process that used a PeerConnection dies, but not when the PeerConnection is stopped (I tested by navigating to another page on the same domain).

Comment 5

[Florian Quèze [:florian]]

Attachment: Bug 1690626 - register the mdns_service thread with the profiler, r=canaltinova.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9678a1277a25
register the mdns_service thread with the profiler, r=canaltinova.

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9678a1277a25