top shows >20% CPU for a chrome task at "OOBE" screen |
||||||
Issue description
Chrome Version: 69.0.3496.0
Chrome OS Version: R69-10894.0.0
Chrome OS Platform: grunt
<b>Network info: <network, encryption type, router model (if known)></b>
Please specify Cr-* of the system to which this bug/feature applies (add
the label below).
Steps To Reproduce:
(0) flash a fresh image onto a system w/ clobbered stateful:
cros flash --board=${B} ${IP} xbuddy://remote/%{B}/latest/test --clobber-stateful
(1) Boot DUT
(2) Let system @ OOBE screen
(3) SSH in to device
(4) top | head -20
Expected Result:
chrome processes consume < 2% CPU while the system is just showing OOBE but otherwise idle.
Actual Result:
1 chrome process consumes > 20% CPU while the system is otherwise idle.
CPU % stays through the OOBE windows, and even on the first "Sign in to your Chromebook" screen.
After signing in (e.g., as guest), CPU$ drops to < 2% for all (idle) Chrome tasks.
For example:
top - 13:11:32 up 50 min, 0 users, load average: 0.45, 0.33, 0.29
Tasks: 215 total, 1 running, 213 sleeping, 0 stopped, 1 zombie
%Cpu(s): 12.1 us, 9.1 sy, 0.0 ni, 78.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3880.9 total, 2614.6 free, 474.9 used, 791.4 buff/cache
MiB Swap: 5684.9 total, 5684.9 free, 0.0 used. 3002.7 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1036 chronos 20 0 650772 169548 64908 S 25.0 4.3 12:24.16 chrome
8830 root 20 0 9808 2672 2000 R 6.2 0.1 0:00.02 top
1 root 20 0 15196 3976 2408 S 0.0 0.1 0:01.04 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/0
8 root 20 0 0 0 0 I 0.0 0.0 0:03.24 rcu_preempt
9 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_sched
10 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh
11 root rt 0 0 0 0 S 0.0 0.0 0:00.01 migration/0
12 root rt 0 0 0 0 S 0.0 0.0 0:00.02 watchdog/0
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
PS shows the full command line for this chrome process:
localhost ~ # ps aux | grep 1036
chronos 1036 24.7 4.3 650772 174272 ? Sl 12:21 12:15 /opt/google/chrome/chrome --type=renderer --enable-logging --enable-webgl-image-chromium --log-level=1 --use-gl=egl --vmodule=*arc/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --field-trial-handle=2170234422078550465,5645769817135235794,131072 --enable-features=Crostini,ExperimentalCrostiniUI,Pepper3DImageChromium --disable-databases --service-pipe-token=13009583710158547452 --lang=en-US --user-data-dir=/home/chronos --homedir=/ --login-profile=user --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=30.0.0.142 --num-raster-threads=1 --service-request-channel-token=13009583710158547452 --renderer-client-id=6 --shared-files=v8_natives_data:100,v8_snapshot_data:101
How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?)
Always.
What is the impact to the user, and is there a workaround? If so, what is it?
Device consumes extra battery / heat while idle at OOBE.
This may also confuse any power measurements that may be taken at this screen.
,
Jul 20
,
Aug 2
Running locally I see low single-core usage caused from animated avatars and the blinking cursor. Both the webui and views-based implementations have this issue.
,
Aug 2
If you switch the profile to a static image and move focus away from the cursor, CPU usage is most frequently at 0.
,
Aug 2
,
Aug 2
This bug isn't discussing the sign in screen, but rather the OOBE screen. That is, the initial welcome screens up to including the first "Sign in to your Chromebook" screen. To get back to OOBE, you can use: crossystem clear_tpm_owner_request=1 Then reboot and check top and you will see something like this (from hana-release/R70-10907.0.0): PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1543 chronos 20 0 405632 120656 37676 S 47.1 3.0 1:08.02 /opt/google/chrome/chrome --type=renderer --enable-logging --log-level=1 --use-gl=egl --vmodule=*arc/*=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_sc+ 1319 chronos 12 -8 510584 137760 86244 S 9.5 3.4 0:16.46 /opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=30.0.0.142 --ui-prioritize-in-gpu-process --use-gl=egl --low-pressure-touch-filtering --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --system-developer-mode -+ 1484 chronos 12 -8 247380 44560 32692 S 3.2 1.1 0:05.28 /opt/google/chrome/chrome --type=gpu-process --field-trial-handle=3663256133009062023,12185027532904034428,131072 --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --vmodule=*arc/*=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_u+ 2660 chronos 20 0 365240 89236 37524 S 2.2 2.2 0:04.35 /opt/google/chrome/chrome --type=renderer --enable-logging --log-level=1 --use-gl=egl --vmodule=*arc/*=1,*/assistant/*=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,*night_light*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_sc+
,
Aug 17
Has anyone else had a chance to repro this? I still see ~50% CPU at idle OOBE.
,
Aug 20
Ah, knowing this only happens on oobe made it easy to repro. Simply start chrome with an empty --user-data-dir and run with --login-manager so that oobe shows up. Top will then indicate a high % CPU usage. Using DevTools showed that there are 60 style recalculations per frame. Pausing animations eliminates the style recalculations. I eventually found that removing the `indeterminate` bit from `paper-progress indeterminate`[1] in the update screen also eliminates the style recalculations. Marking RBB m-71 to make sure this is fixed in post-70 cleanup. 1: https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_update.html?l=37&rcl=b4064e96f0a3e6df677d8e35b5958f693e34b7a4
,
Aug 20
This is great to hear... but if it is a one line change, why not land on ToT/M-70 since we are still pre-branch point?
,
Aug 20
Associating the indeterminate attribute with visibility to stop the style recacls is just one possible option, but not a great one because it is working around the actual issue of indeterminate being extremely inefficient. We should try to get this fixed upstream or possibly implement a paper-progress component ourselves that does not have this problem. It may end up that working around the inefficiency is the best solution, but we should evaluate the other options.
,
Aug 27
,
Aug 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3079ba7d841f1430a5f6e910f6707e8103b0f647 commit 3079ba7d841f1430a5f6e910f6707e8103b0f647 Author: Alexander Alekseev <alemate@chromium.org> Date: Mon Aug 27 21:57:58 2018 Chrome OS OOBE: do not animate hidden paper-progress element. Paper-progress in 'indeterminate' state will recalculate its style on every frame, which leads to high CPU load even when ths screen with this element is hidden. This CL ensures this attribute is set only before object is shown, and paper-progress is marked hidden when it is no longer visible. Bug: 866117 Change-Id: Ia64171b3e10df2bc564f03f9c3c007a2971cee26 Reviewed-on: https://chromium-review.googlesource.com/1188500 Reviewed-by: Jacob Dufault <jdufault@chromium.org> Commit-Queue: Alexander Alekseev <alemate@chromium.org> Cr-Commit-Position: refs/heads/master@{#586437} [modify] https://crrev.com/3079ba7d841f1430a5f6e910f6707e8103b0f647/chrome/browser/resources/chromeos/login/oobe_update.html [modify] https://crrev.com/3079ba7d841f1430a5f6e910f6707e8103b0f647/chrome/browser/resources/chromeos/login/oobe_update.js
,
Aug 27
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by abodenha@google.com
, Jul 20