Trace file attached

Deleted: trace_slowtabs.json.gz 2.9 MB

trace_slowtabs.json.gz 2.9 MB Download

Thanks for the report!

@Victor CommandBufferService:PutChanged seems to be taking 1 second each call, way too high. Could you help triage?

cc rpop fyi because tabs

May be related to  bug 848210 ?

twood@, thanks for the report.  Could you please attach a copy of the output from navigating to "chrome://gpu"?  Did this work on an earlier version of Chrome?

ccameron@ have you seen anything like this in the past?

twood@
Can you see the deprecation message of Synchronous XMLHttpRequest in DevTools?

> [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.

If so this is the same issue as the  issue 848210 .

@ Reporter: As per comment #6 could you please confirm the issue.Hence adding Needs-Feedback label.

Thanks.! 

horo@, I've checked a few different pages and do not see any mention of XMLHttpRequest in the console. In checking various sites I noticed the tab containing this thread began exhibiting the behavior described. I noticed the slowdown was not immediate. Switching to the tab seems to perform as expected for a short while. After opening about a half dozen tabs over the course of about 15 minutes to check for XMLHttpRequest, I returned to this thread and noticed considerable latency in the time between the tab focus switching and the content of the screen rendering (pausing for several seconds at a blank white screen).

ccameron@, You'll find the chrome://gpu report attached

Deleted: gpu.report 45.5 KB

gpu.report 45.5 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Apologies for the comment spam. Moments after posting #9 I discovered this behavior is not exhibited without my external monitor connected. The gpu report above is from no external monitor attached. In case the information is different/relevant I've generated and attached another report from chrome://gpu with the external monitor attached.

Deleted: gpu2.report 52.5 KB

gpu2.report 52.5 KB Download

Issue 848952 has been merged into this issue.

Oops, this is a separate bug from issue 848952 -- this is not related to ClearLevel.

The trace attached for this bug is calling ClearLevel, but that only accounts for a tiny fraction of the slowness.

The PutChanged calls are lasting exactly 1 second, and there are lots of them. That sounds like something going wrong in scheduling (either on our side or on Apple's side). Adding sunnyps to take a look

(and separating off the ClearLevel issue).

Deleted: wait.png 106 KB

	wait.png 106 KB View Download

->sunnyps to take a look at the "exactly 1 second" issue in the trace

-> ccameron's fix is here: https://chromium-review.googlesource.com/c/chromium/src/+/1083782

Operating system	Mac OS X 10.13.4
GPU0	VENDOR = 0x1002, DEVICE= 0x6821
GPU1	VENDOR = 0x8086, DEVICE= 0x0d26 *ACTIVE*

I'm seeing that, when using the dGPU on my machine, some GL calls are extremely slow. Haven't figured out why -- it might be a regression in 10.13.4.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a3d6a216d1aacfe441cd1874cf96cbeae24f69f6

commit a3d6a216d1aacfe441cd1874cf96cbeae24f69f6
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Jun 07 02:39:58 2018

Add instrumentation for macOS jank

We are seeing very long calls to TexSubImage2D. Add instrumentation
to determine which path is being taken when this is slow (not all
calls are slow).

We are seeing lots of time in ClientWait in
ImageTransportSurfaceOverlayMac. Add instrumentation to determine
in which part of the function we are spending time.

Bug: 848464
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Ic8b5835d0373e93863462e1580cc9875b5699fdf
Reviewed-on: https://chromium-review.googlesource.com/1090218
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565155}
[modify] https://crrev.com/a3d6a216d1aacfe441cd1874cf96cbeae24f69f6/gpu/command_buffer/service/texture_manager.cc
[modify] https://crrev.com/a3d6a216d1aacfe441cd1874cf96cbeae24f69f6/gpu/ipc/service/image_transport_surface_overlay_mac.mm

Issue 807037 has been merged into this issue.

Could this be a similar or dupe of issue 851506?

The next time you see this:

to get the pid of the browser process, run:

ps aux | grep "Google Chrome" | grep -v "type" | grep -v "Framework" | grep -v "grep" | awk  '{print $2}'

Then run:

vmmap -v -interleaved [insert_pid_here] > /tmp/vmmap.txt

Slack is encountering this as well, as far back as Chrome 61 | Electron 2.0.2. Interestingly macOS 10.13.3 / 10.13.4 don't seem to be affected, so your theory that this depends on some system call that changed in 10.13.5 seems reasonable.

Other findings:

* So far every repro we have is specific to the AMD Radeon R9 dGPU
* Disconnecting the external monitor or forcing iGPU using --disable-gpu makes the problem go away