The compiz failure makes me think this is something I used to see regularly in internal builds but never could reproduce - do you have repro steps? In my experience it seemed to happen when I had opened a site that made particularly heavy use of Canvas2D, and then let the Linux machine screensaver activate.

Alas, no repro steps. However, I just rebooted and fired up Chrome - it restored my previous browser session of two pinned tabs of Gmail and Google Reader, and compiz and Chrome were fighting for CPU (with Xorg, too):

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 1664 xxxxxxxx  20   0  759m 208m  45m S   31  4.2   1:11.67 compiz             
 2104 xxxxxxxx  20   0 1164m  76m  35m S   21  1.5   0:43.00 chrome             
 1118 root      20   0  368m 173m  26m S   20  3.5   0:36.30 Xorg               

Regarding Canvas2D, I'm not using any hardware accelerated rendering as my GPU has been blacklisted. Don't know if this is relevant. Also, for me, this CPU hogging isn't related to the screensaver kicking in, as it hasn't kicked in yet since I rebooted.

I've been trying to avoid this bug by moving to the beta, then stable, channels as it appeared in each of them. It's now biting me with the new stable release (15.0.874.102), so I've now got no option of a version of Chrome that doesn't chew 50% of my CPU usage (100% of one core) seemingly all the time.

I guess none of the Chrome engineers can reproduce this, but if anyone can give me any pointers on how I may go about debugging this to find out more about it, I'd be more than happy.

I have the same problem, and it seems that this is tied to the pined tabs flashing when a modification is detected on a page (facebook, gmail, etc.). Iconizing the browser fix the problem, but this is not a solution.

Ubuntu 11.10 x86_64

High CPU usage between compiz and chromium; only occurs with pinned tab (Gmail) in a flashing notification state.

Once the notification has been acknowledged (click the tab), CPU usage drops to normal.

I confirm the high CPU usage when a pinned tab is pulsing, but I want to add that I think the same problem happens for other kind of "activity" in the tab.

For example, if a website (in a pinned tab or not) takes ages to reply, and chromium shows the "grey spinning wheel" icon, I observe 100% CPU usage until I press the button to abort the operation.

I'm using chromium "15.0.874.106 (Build 107270 Linux) Ubuntu 11.10" on an up to date Ubuntu with Unity (3d) and compiz.

I might be very wrong, but I think that this has to do with compiz - I observed the same behavior on a spinning icon in a very different application: when network-manager is connecting to a wireless network and the icon displays the wifi "waves" lighting one after the other. Sorry I haven't  a bugreport for any of them to support my claim.

I have this same functionality too, both on Ubuntu 12.04 and 11.04 both 64bit.  Again have seen it when the pinned tabs are "flashing" and also while a page is loading.

Also running the nvidia drivers and Ubuntu 12.04 was a clean install too.

This continues to happen for me. linux/amd64/ubuntu 12.04, chromium 18. The circumstances of chrome and compiz going into a loop always coincide with the gmail tab pulsing to let me know a notification as arrived.

I have this problem as well using ubuntu 12.04 and chromium 20.

Same here and it's very annoying. You get an email and compiz drains your battery :(

I have this issue too, although I do not have a pinned flashing tab (I have many pinned tabs but none is flashing) and I'm not using compiz. I find chrome constantly using around 12-25% CPU which seems to force XOrg to use another 20%. I tried beta (at present Version 21.0.1180.57 beta) but the problem is still there. Strace shows _a lot_ of this:

recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"%\30\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
write(11, "!", 1)                       = 1
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=90, events=POLLIN}, {fd=191, events=POLLIN}], 4, 0) = 0 (Timeout)
read(9, 0x7fffe2ad6ab0, 16)             = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"5\30\4\0\220\302\2\4\276\0\0\4`\0\20\0\230\4\6\0\221\302\2\4\220\302\2\4\21\2\0\0\0\4\0\0\1\0\0\0\230\32\t\0\1\0\0\0\221\302\2\4\304\304\275\275\260\260\377\377P\0\0\0\20\0\20\0\0\0\0\0\20\0\20\0;\3\7\0\307\0\0\4\0\0\0\0\0\0\0\0\20\0\20\0P\0\0\0\20\0\20\0008\0\5\0\307\0\0\4\0000\0\0#\377\377\377\372\377\377\377F\302\5\0\220\302\2\4\307\0\0\4#\377\372\377\220\6\32\0048\0\4\0\307\0\0\4\0\0\10\0\0\0\0\0\230\6\7\0\221\302\2\4\0\0\0\0P\0\0\0\20\0\20\0\0\0\0\0\20\0\20\0\230\10\t\0\3\1\0\4\315\1\0\4\0\0\0\0\221\302\2\4\335\0\25\0\0\0\0\0\0\0\0\0`\0\20\0\230\5\4\0\221\302\2\4@\0\0\0\0\0\0\0\230\10\t\0\3\0\0\0t\1\0\4\0\0\0\0\221\302\2\4\335\0\6\0\0\0\0\0\0\0\0\0\20\0\20\0\230\10\t\0\3\302\2\4#\2\0\4\0\0\0\0\221\302\2\4\200\0\0\0\0\0\0\0\0\0\0\0\20\0\20\0\230\10\t\0\3\10\t\0t\1\0\4\0\0\0\0\221\302\2\4-\1\6\0P\0\0\0P\0\0\0\20\0\20\0\230\10\t\0\3\10\t\0#\2\0\4\0\0\0\0\221\302\2\0040\n\0\0P\0\0\0P\0\0\0\20\0\20\0\230\7\2\0\221\302\2\4;\3\7\0\302\0\0\4\0\0\0\0\335\0\6\0\20\0\20\0-\1\6\0\20\0\20\0>\0\7\0\220\302\2\4\276\0\0\4\302\0\0\4\0\0\0\0\335\0\6\0`\0\20\0008\0\4\0\302\0\0\4\0\0\10\0\0\0\0\0006\0\2\0\220\302\2\4", 472}, {NULL, 0}, {"", 0}], 3) = 472
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=90, events=POLLIN}, {fd=191, events=POLLIN}, {fd=10, events=POLLIN}], 5, 0) = 1 ([{fd=10, revents=POLLIN}])
read(9, 0x7fffe2ad6ab0, 16)             = -1 EAGAIN (Resource temporarily unavailable)
read(10, "!", 1)                        = 1
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=90, events=POLLIN}, {fd=191, events=POLLIN}, {fd=10, events=POLLIN}], 5, 0) = 0 (Timeout)
read(9, 0x7fffe2ad6ab0, 16)             = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(8, 0x7fa5afa08074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}, {fd=90, events=POLLIN}, {fd=191, events=POLLIN}, {fd=10, events=POLLIN}], 5, 8) = 0 (Timeout)
read(9, 0x7fffe2ad6ab0, 16)             = -1 EAGAIN (Resource temporarily unavailable)
write(11, "!", 1)                       = 1

A naive first impression would be that its stuck in a very tight loop waiting on a timer that keeps on firing - very similar to the leap second problems we had recently...

OK, so it seems I've been bitten by the libcairo2 problem:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672364

Since a few of you guys on this thread are saying you are experiencing a problem on Ubuntu I believe my problem is unrelated to yours - Ubuntu is shipping the libcairo patch whereas Debian is not. I still have a residual constant usage of CPU of around 6% which I can't explain but its not enough to justify spending time on it. the big 15-50% CPU usage is gone with a patched libcairo.

same problem here on ubuntu 12.10 ( using Xfce or E17 ... so it is not compiz related )

I am hitting this issue very consistently now.

Google Chrome 37.0.2024.2 dev
Ubuntu 14.04 Linux 3.13.0-8-generic #28-Ubuntu SMP Tue Feb 11 17:55:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

strace is just a continuous stream of:

recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout)
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout)
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 79) = 1 ([{fd=16, revents=POLLIN}])
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
read(16, "!", 2)                        = 1
recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout)
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 0 (Timeout)
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 45) = 0 (Timeout)
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
write(17, "!", 1)                       = 1
recvmsg(9, 0x7fffa4065510, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(14, 0x7fffa4065520, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=10, events=POLLIN}, {fd=9, events=POLLIN}, {fd=14, events=POLLIN}, {fd=15, events=POLLIN}, {fd=81, events=POLLIN}, {fd=16, events=POLLIN}], 6, 0) = 1 ([{fd=16, revents=POLLIN}])
recvmsg(14, 0x7fffa4065550, 0)          = -1 EAGAIN (Resource temporarily unavailable)
read(16, "!", 2)                        = 1

A perf capture:

+  53.64%  chrome  [kernel.kallsyms]           [k] 0xffffffff8104f45a
+  24.57%  chrome  libnvidia-glcore.so.331.38  [.] 0x00000000016dc3e3
+  17.36%  chrome  libGL.so.331.38             [.] 0x00000000000a7659
+   1.91%  chrome  perf-2650.map               [.] 0x0000000041cebfba
+   1.22%  chrome  chrome                      [.] 0x000000000431f121
+   0.63%  chrome  libc-2.19.so                [.] __sched_yield
+   0.06%  chrome  [vdso]                      [.] 0x0000000000000701
+   0.05%  chrome  libc-2.19.so                [.] memset
+   0.05%  chrome  libpthread-2.19.so          [.] pthread_mutex_lock
+   0.05%  chrome  libxcb.so.1.1.0             [.] 0x000000000000bcfb
+   0.04%  chrome  libc-2.19.so                [.] _wordcopy_fwd_aligned
+   0.04%  chrome  libglib-2.0.so.0.4000.0     [.] 0x000000000008a62d
+   0.04%  chrome  libpthread-2.19.so          [.] pthread_getspecific
+   0.04%  chrome  libpthread-2.19.so          [.] pthread_mutex_unlock
+   0.02%  chrome  libpthread-2.19.so          [.] 0x000000000000f8ad
+   0.02%  chrome  libc-2.19.so                [.] __memmove_sse2
+   0.02%  chrome  chrome                      [.] operator new(unsigned long)
+   0.02%  chrome  libX11.so.6.3.0             [.] 0x000000000003b896
+   0.02%  chrome  libGL.so.331.38             [.] sched_yield@plt
+   0.02%  chrome  libXext.so.6.4.0            [.] XextFindDisplay
+   0.02%  chrome  libc-2.19.so                [.] 0x00000000000fb9a7
+   0.01%  chrome  libc-2.19.so                [.] _wordcopy_fwd_dest_aligned
+   0.01%  chrome  libc-2.19.so                [.] __memcmp_sse2
+   0.01%  chrome  libc-2.19.so                [.] __GI___libc_poll
+   0.01%  chrome  libpthread-2.19.so          [.] pthread_cond_broadcast@@GLIBC_2.3.2
+   0.01%  chrome  libc-2.19.so                [.] __libc_disable_asynccancel
+   0.01%  chrome  libpthread-2.19.so          [.] __errno_location
+   0.01%  chrome  libX11.so.6.3.0             [.] _XReply
+   0.01%  chrome  chrome                      [.] pthread_getspecific@plt
+   0.01%  chrome  chrome                      [.] malloc
+   0.01%  chrome  libGL.so.331.38             [.] glXGetCurrentContext

With syms:

+  24.57%  chrome  libnvidia-glcore.so.331.38  [.] 0x00000000016dc3e3
+  17.36%  chrome  libGL.so.331.38             [.] 0x00000000000a7659
+   5.92%  chrome  [kernel.kallsyms]           [k] sk_run_filter
+   5.00%  chrome  [kernel.kallsyms]           [k] sched_clock
+   3.53%  chrome  [kernel.kallsyms]           [k] __acct_update_integrals
+   2.29%  chrome  [kernel.kallsyms]           [k] vtime_account_user
+   2.25%  chrome  [kernel.kallsyms]           [k] context_tracking_user_exit
+   2.22%  chrome  [kernel.kallsyms]           [k] ktime_get_ts
+   2.11%  chrome  [kernel.kallsyms]           [k] local_clock
+   2.03%  chrome  [kernel.kallsyms]           [k] vtime_user_enter
+   1.91%  chrome  perf-2650.map               [.] 0x0000000041cebfba
+   1.78%  chrome  [kernel.kallsyms]           [k] sched_clock_cpu
+   1.42%  chrome  [kernel.kallsyms]           [k] native_read_tsc
+   1.33%  chrome  [kernel.kallsyms]           [k] context_tracking_user_enter
+   1.26%  chrome  [kernel.kallsyms]           [k] cpuacct_account_field
+   1.22%  chrome  chrome                      [.] 0x000000000431f121
+   1.18%  chrome  [kernel.kallsyms]           [k] system_call_after_swapgs
+   1.16%  chrome  [kernel.kallsyms]           [k] retint_swapgs
+   1.13%  chrome  [kernel.kallsyms]           [k] system_call
+   0.94%  chrome  [kernel.kallsyms]           [k] syscall_trace_enter
+   0.86%  chrome  [kernel.kallsyms]           [k] copy_user_generic_string
+   0.83%  chrome  [kernel.kallsyms]           [k] native_sched_clock
+   0.78%  chrome  [kernel.kallsyms]           [k] put_prev_task_fair
+   0.67%  chrome  [unknown]                   [k] 0xffffffffa04c629b
+   0.67%  chrome  [kernel.kallsyms]           [k] acct_account_cputime
+   0.67%  chrome  [kernel.kallsyms]           [k] tracesys
+   0.66%  chrome  [kernel.kallsyms]           [k] get_vtime_delta
+   0.63%  chrome  libc-2.19.so                [.] __sched_yield
+   0.63%  chrome  [kernel.kallsyms]           [k] __secure_computing
+   0.59%  chrome  [kernel.kallsyms]           [k] rcu_eqs_enter_common.isra.47
+   0.58%  chrome  [kernel.kallsyms]           [k] account_system_time
+   0.56%  chrome  [kernel.kallsyms]           [k] jiffies_to_timeval
+   0.54%  chrome  [kernel.kallsyms]           [k] seccomp_bpf_load
+   0.53%  chrome  [kernel.kallsyms]           [k] _raw_spin_lock
+   0.48%  chrome  [kernel.kallsyms]           [k] rcu_eqs_exit_common.isra.48
+   0.47%  chrome  [kernel.kallsyms]           [k] update_curr
+   0.41%  chrome  [kernel.kallsyms]           [k] int_check_syscall_exit_work
+   0.38%  chrome  [kernel.kallsyms]           [k] sys_clock_gettime
+   0.34%  chrome  [kernel.kallsyms]           [k] account_user_time
+   0.34%  chrome  [kernel.kallsyms]           [k] rcu_eqs_exit
+   0.33%  chrome  [kernel.kallsyms]           [k] syscall_trace_leave

We're also seeing this issue on Google-internal Ubuntu 12.04 and 14.04 amd64 machines with NVIDIA graphics cards. If a Chrome developer needs a machine to look at please get in touch with me.

May mostly be a dupe of  issue 98869 

Still there with version 45.*. The flashing/animated pinned tab does account for about ~25 glXSwapBuffers() calls per second (probably 1s/kPinnedTitleChangeAnimationIntervalMS... 1s/40ms) and lot's of OnAsyncFlush messages in the GPU command buffer. Could be the synchronization with X in glXSwapBuffers() that's costly. When attaching gdb and directly returning from Tab::StartPinnedTabTitleAnimation(), there's no CPU penalty at all. 

Anyway, while looking into this really annoying issue, I noticed, that the animation isn't even stopped if the flashing pinned tab is activated. It only stops if _switching away_ from that pinned tab after selecting it. Thus I came up with the attached patch.

chromium-45.0.2454.15_call_StopPinnedTabTitleAnimation_in_ActiveStateChanged.patch 706 bytes Download

Ugh, for a pinned animating tab (and the hovering effect on tabs) I get a huge amount of mem*() function calls on the gpu-process, especially memcmp():

time ltrace -f -T -c -e mem*@MAIN -p 9444 
% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
 84.42    4.425696         348     12686 memcmp
 10.47    0.548794         346      1586 memcpy
  4.84    0.253682         427       594 memset
  0.27    0.014028         359        39 memmove
------ ----------- ----------- --------- --------------------
100.00    5.242200                 14905 total

real    0m7.960s
user    0m0.890s
sys     0m4.220s

If there's no tab animation there's little to no mem*() calls. That huge amount of memory access could be the reason for the CPU usage. Which by the way is ridiculous for a 50x50 piece of pixels.


Most likely, these 64byte memcpy() calls originate from Mailbox gpu/command_buffer/common/mailbox.h

  bool operator<(const Mailbox& other) const {
    return memcmp(this, &other, sizeof other) < 0;
  }
  bool operator==(const Mailbox& other) const {
    return memcmp(this, &other, sizeof other) == 0;
  }

which is called multiple times (log(mailboxes) for sorted std::map) for every MailboxManagerImpl::ConsumeTexture(), due to

  MailboxToTextureMap::iterator it = mailbox_to_textures_.find(mailbox);

Probably using an std::unordered_map would benefit performance (constant time), though a hasher for that Mailbox::Name would be needed.


With the attached patch using a std::unordered_map I was able to reduce the memcmp() calls. CPU usage for gpu-process seems to have dropped a bit. Still way too many draw events for such a simple animation.

time ltrace -f -T -c -e *mem*@* -p 19812
% time     seconds  usecs/call     calls      function
------ ----------- ----------- --------- --------------------
 50.11    1.260628         427      2952 memcmp
 33.90    0.852804         426      1998 memcpy
 15.35    0.386028         517       746 memset
  0.64    0.016024         381        42 memmove
------ ----------- ----------- --------- --------------------
100.00    2.515484                  5738 total

real    0m10.024s
user    0m0.443s
sys     0m2.117s

chromium-45.0.2454.15_use_unordered_map_for_mailbox.patch 1.9 KB Download

Adding Cr-Internals-GPU-Internals per comment 24 which has evidence that command buffers / gpu mailboxes are to blame.

I've been seeing this for years on linux (using arch linux), both chromium-dev branch and stable whenever a pinned tab flashes because a notification. 

An example I've discovered as an easy trigger on chromium 48.0.2547.0 is for example pinning an slack tab, closing an resuming session because somehow it emits a notification when loaded. 

I don't know almost a thing about chromium / chrome internals but I'd like to contribute - see this fixed. How may I be of help?

These patches make the problem go away by completely disabling the pinned tab animations.

It's not a proper fix, but at least chromium isn't hogging all your CPU this way.

chromium-45.0.2454.85_never_use_pinned_tab_title_animation.patch 359 bytes Download

I've also been noticing this on Google-internal Ubuntu 14.04 since the beginning of October 2015. compiz is at 100% and the UI is completely locked up (strace shows lots of clock_gettime(CLOCK_MONOTONIC, ...)).

This looks like it's partly related to the pinned tab flashing issue: https://code.google.com/p/chromium/issues/detail?id=98869

But also looks like there are a number of issues mixed up here - the original bug seems to be similar to xcb event polling issue https://code.google.com/p/chromium/issues/detail?id=550961 or maybe a sandbox issue.

I experience this symptom very often. I tried the "fix" in #19 and indeed fixed it, but also crashed a chrome process so it might be a cause of that.

 issue 98869  says that CPU is at about 20%. What I experienced is one CPU at near 100% running chrome and another CPU at near 100% running the X server (I have 4 CPUs). Killing the GPU process every now and then also helps to reduce the impact of this bug.

Symptoms are consistent with  issue 550961 , closing as duplicate.