Share via

Team on Linux consumes 1 cpu core checking current cpu scaling_governor and power supply status 1.5 million times per second

Ben Werthmann 6 Reputation points
2020-04-06T16:14:01.587+00:00

Hello,

Teams is opening and reading these two files as fast as it can consuming one core of my linux laptop. 

23481 teams 70 0 /sys/class/power_supply/AC/online  
23481 teams 70 0 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

In 60 seconds I've observed 1,568,360 opens.

Related FlameGraph:

6956-2020-04-06-12-07-09-teams-flamegraph-acpi.png

Are debug symbols available for teams? If so, we can probably isolate the origin codepath...

Skype for Business Linux
Skype for Business Linux
Skype for Business: A Microsoft communications service that provides communications capabilities across presence, instant messaging, audio/video calling, and an online meeting experience that includes audio, video, and web conferencing.Linux: A family of open-source Unix-like operating systems.
456 questions

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. JimmyYang-MSFT 50,446 Reputation points Microsoft Vendor
    2020-04-07T09:48:51.717+00:00

    Hi BenWerthmann-2645!
    I tried to find if there are any documents referring to debug symbol in Microsoft Teams for Linux but didn’t find anything useful official documents support about it. Maybe you can try to see if it can be applied well in Teams for Linux. For more details about how to debug packages with debug symbol, you can refer to: https://www.hiroom2.com/2018/04/27/ubuntu-1804-dbgsym-en/

  2. Marian Javorka - MSFT 936 Reputation points Microsoft Employee
    2020-06-18T17:09:44.58+00:00

    @RodeKater @Ben Werthmann thanks again for your help with logs and debug details. We released new insiders version yesterday (version 1.3.00.16851) and this version should have fixes in this area. Can you maybe try out this version and see if it helps? Alternatively, if you don't want to go to insiders and want to stick with Preview version, this should get updated next week

    0 comments
  3. RodeKater 1 Reputation point
    2020-06-18T13:57:13.903+00:00

    Hi @Marian Javorka - MSFT @JimmyYang-MSFT , it doesn't happen all the time, though it seems to be something relating to calls. The teams backend seems to get stuck in a loop triggering itself. I've caught an strace of when it's broken, it looks like this: 

    # Thread B (which reads the files) is waiting on a lock  
4665  14:51:55.973754 futex(0x7f61600036f0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1592484721, tv_nsec=483743000}, FUTEX_BITSET_MATCH_ANY <unfinished ...>  
# Thread A gets a message to wake up. What the epoll is doing is unclear.  
# Note: FD72 = /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC/online  
# Note: FD47&48 are the two sides of a pipe  
32114 14:51:55.973764 read(47, "\0", 100) = 1  
32114 14:51:55.973787 read(47, 0x7f6169493500, 100) = -1 EAGAIN (Resource temporarily unavailable)  
32114 14:51:55.973809 epoll_ctl(46, EPOLL_CTL_MOD, 72, {EPOLLPRI|EPOLLET, {u32=3356329872, u64=140053649917840}}) = 0  
32114 14:51:55.973831 epoll_wait(46, [{EPOLLPRI|EPOLLERR, {u32=3356329872, u64=140053649917840}}], 32, -1) = 1  
32114 14:51:55.973853 read(47, 0x7f6169493500, 100) = -1 EAGAIN (Resource temporarily unavailable)  
# Thread A wakes thread B, fiddle some locks (RWLock maybe?)  
32114 14:51:55.973875 futex(0x7f61600036f0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>  
4665  14:51:55.973888 <... futex resumed> ) = 0  
32114 14:51:55.973897 <... futex resumed> ) = 1  
4665  14:51:55.973904 futex(0x7f61600036a0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>  
32114 14:51:55.973911 futex(0x7f61600036a0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>  
4665  14:51:55.973919 <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)  
32114 14:51:55.973926 <... futex resumed> ) = 0  
4665  14:51:55.973934 futex(0x7f61600036a0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>  
# Thread A goes to sleep  
32114 14:51:55.973941 epoll_wait(46,  <unfinished ...>  
4665  14:51:55.973953 <... futex resumed> ) = 0  
# Thread B gets info about power supply and CPU governer  
4665  14:51:55.973966 openat(AT_FDCWD, "/sys/class/power_supply/AC/online", O_RDONLY) = 70  
4665  14:51:55.973998 read(70, "1\n", 128) = 2  
4665  14:51:55.974508 read(70, "", 126) = 0  
4665  14:51:55.974531 close(70)         = 0  
4665  14:51:55.974555 openat(AT_FDCWD, "/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_RDONLY) = 70  
4665  14:51:55.974585 read(70, "performance\n", 128) = 12  
4665  14:51:55.974610 read(70, "", 116) = 0  
4665  14:51:55.974632 close(70)         = 0  
# Thread B writes results to pipe  
4665  14:51:55.974655 write(48, "\0", 1) = 1  
# This wakes Thread A, which causes the cycle to repeat  
32114 14:51:55.973742 <... epoll_wait resumed> [{EPOLLIN, {u32=0, u64=0}}], 32, -1) = 1  
--- repeat ---  
4665  14:51:55.973754 futex(0x7f61600036f0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1592484721, tv_nsec=483743000}, FUTEX_BITSET_MATCH_ANY <unfinished ...>  
32114 14:51:55.973764 read(47, "\0", 100) = 1  
32114 14:51:55.973787 read(47, 0x7f6169493500, 100) = -1 EAGAIN (Resource temporarily unavailable)  
32114 14:51:55.973809 epoll_ctl(46, EPOLL_CTL_MOD, 72, {EPOLLPRI|EPOLLET, {u32=3356329872, u64=140053649917840}}) = 0  
32114 14:51:55.973831 epoll_wait(46, [{EPOLLPRI|EPOLLERR, {u32=3356329872, u64=140053649917840}}], 32, -1) = 1  
32114 14:51:55.973853 read(47, 0x7f6169493500, 100) = -1 EAGAIN (Resource temporarily unavailable)

    etc etc etc

    Hope this helps identify the problem...

    0 comments