My CPU is AMD A6-9220 RADEON R4. I use Ubuntu 16.04.1. No additional (proprietary) drivers available. CPU loads both in Chrome and Firefox, hardware acceleration is off in Chrome. It happens when I scroll page mostly. Or when browser open and I do something else (run some other tasks). Something wrong exactly with browsing, I can do much more heavy tasks without such reaction from CPU (I can watch HD-videos for instance from HDD without making it load more than 23%). As top command showed it's mostly Xorg process that eats a lot (50%).

enter image description here

  • I do not know your exact situation - which sites you use, how heavy are they. If you mean modern endless-scrollable sites, then it may be normal for such hardware. But from my personal experience I can say that entry-level A6 (or A4-4000 in my case) are tremendously slow. By accident I switched to Haswell Pentium G34xx, and even it is faster than that old AMDs.
    – N0rbert
    Aug 29, 2018 at 15:48
  • @N0rbert this site for instance, YouTube... any site, I can watch HD videos on my HDD without loading CPU more than 23%, it's 2.5Ghz.
    – R S
    Aug 29, 2018 at 16:16
  • 1
    vidarlo's answer below has link to benchmarks. Your CPU is slow (as my A4 too). Modern web-browsers are resource-hungry. JavaScript may be an answer. JIT, or something. See this article on Mozilla's blog.
    – N0rbert
    Aug 29, 2018 at 16:19
  • @N0rbert top shows that it' mostly Xrog process's falult, it eats about 50% on scrolling.
    – R S
    Aug 29, 2018 at 18:36

3 Answers 3


So, you got me curious, and I decided to profile Xorg a bit. Note: I don't have debug symbols installed (and you can't really trust them with optimized code anyway), so the output I got is somewhat scarce, but nonetheless…

$ sudo operf --pid=$(pgrep Xorg) # scroll youtube in chromium for a bit, then interrupt the command
$ opreport -l | head -n 20
[warnings skipped]
CPU: AMD64 family12h, speed 1900 MHz (estimated)
Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        image name               symbol name
6030     26.0351  r600_dri.so              /usr/lib/dri/r600_dri.so
4717     20.3661  Xorg                     /usr/lib/Xorg
2616     11.2948  radeon                   /radeon
1135      4.9005  drm                      /drm
833       3.5966  libc-2.28.so             _IO_vfscanf
793       3.4239  ttm                      /ttm
686       2.9619  radeon_drv.so            /usr/lib/xorg/modules/drivers/radeon_drv.so
642       2.7719  libglamoregl.so          /usr/lib/xorg/modules/libglamoregl.so
524       2.2624  libEGL_mesa.so.0.0.0     /usr/lib/libEGL_mesa.so.0.0.0
476       2.0552  libc-2.28.so             arena_get2.part.4
465       2.0077  libGLdispatch.so.0.0.0   /usr/lib/libGLdispatch.so.0.0.0
397       1.7141  libglapi.so.0.0.0        /usr/lib/libglapi.so.0.0.0
345       1.4896  libc-2.28.so             exec_comm
328       1.4162  libEGL.so.1.1.0          /usr/lib/libEGL.so.1.1.0
325       1.4032  libpixman-1.so.0.34.0    /usr/lib/libpixman-1.so.0.34.0
178       0.7685  libdrm.so.2.4.0          /usr/lib/libdrm.so.2.4.0
154       0.6649  libfb.so                 /usr/lib/xorg/modules/libfb.so

Here even more time than in Xorg itself being spent in r600_dri, which is a userspace graphics driver.

The conclusion we can make is that to reduce CPU overhead you need to upgrade your drivers, because there (as in any project, FWIW) constantly new optimizations are going. Of course you hardly notice a difference from a few months of work, but maan, the 11.2.x Mesa version that your 16.04 is using is ancient!

For comparison I pulled up Firefox on youtube, and scrolled for a bit there. Results are below; a number of samples is a bit bigger, perhaps because I scrolled more intensively, or longer, or both.

CPU: AMD64 family12h, speed 1900 MHz (estimated)
Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        image name               symbol name
13128    41.2558  libc-2.28.so             arena_get2.part.4
8628     27.1142  r600_dri.so              /usr/lib/dri/r600_dri.so
2534      7.9633  Xorg                     /usr/lib/Xorg
1832      5.7572  radeon                   /radeon
776       2.4386  drm                      /drm
677       2.1275  ttm                      /ttm
565       1.7756  libc-2.28.so             _IO_vfscanf
392       1.2319  libglamoregl.so          /usr/lib/xorg/modules/libglamoregl.so
279       0.8768  libEGL_mesa.so.0.0.0     /usr/lib/libEGL_mesa.so.0.0.0
276       0.8674  radeon_drv.so            /usr/lib/xorg/modules/drivers/radeon_drv.so
269       0.8454  libGLdispatch.so.0.0.0   /usr/lib/libGLdispatch.so.0.0.0
242       0.7605  libc-2.28.so             exec_comm
212       0.6662  libglapi.so.0.0.0        /usr/lib/libglapi.so.0.0.0
178       0.5594  libpixman-1.so.0.34.0    /usr/lib/libpixman-1.so.0.34.0
160       0.5028  libEGL.so.1.1.0          /usr/lib/libEGL.so.1.1.0
95        0.2985  libfb.so                 /usr/lib/xorg/modules/libfb.so
86        0.2703  libdrm.so.2.4.0          /usr/lib/libdrm.so.2.4.0

This time the difference between graphics driver and Xorg is even bigger, in preference of the driver.

However, interestingly, the most dominating entry was glibc's arena_get2.part.4. What could that be? I couldn't find the exact result on google, but I did find this source file which suggests it's most likely about memory allocation.

To reduce the impact of this one you would probably be interested in per-thread malloc cache optimization that is part of glibc 2.26 release. Nowadays, after all that Spectre and Meltdown stuff happened, the optimization matters even more as it becomes even more important to not go into kernel space too often.

I presume, it's libc6 package that Ubuntu Xenial has at 2.23 version. You might be tempted to upgrade this specific one package, but be admonished that it might break something, because this library is at the very core of the system. The best way to get it would be upgrading to 18.04 which has 2.27 version.

  • I tried Lubuntu 18.04 - the same on scrolling.
    – R S
    Aug 31, 2018 at 2:22
  • @RS same as in "same amount of CPU loaded", or as in "still takes a bunch of CPU, but less than it did in 16.04"?
    – Hi-Angel
    Aug 31, 2018 at 16:41
  • like "same amount of CPU loaded", no difference at all.
    – R S
    Aug 31, 2018 at 20:43
  • Well, this is odd. I don't think I can add anything to it, except perhaps α) manually building Mesa and Xorg for your system with lots of manually set optimizations, and β) actually searching what code execute most often in Xorg, and optimizing these paths.
    – Hi-Angel
    Sep 1, 2018 at 9:56

Interestingly I have an r300-era card (Mobility Radeon 200M) and much more ancient CPU in my laptop and both were faster than the problem case described here and without CPU spikes - until I have upgraded my system!

First I thought it is the kernel, but downgrading to old Xorg and mesa made everything faster than ever.

I do not know what is going on, but for some reason, GPU acceleration became much more CPU-intensive. Also in my perf output, I mostly see memory movements taking place in most of the times. On my single core CPU that makes 100% CPU usage, while reverting to an old mesa+xorg I get at most 25-40% and not in the GPU drivers. Something clearly got wrong at one point.

See here for full analysis: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1099745-how-to-tell-if-a-driver-is-gallium-or-just-mesa-slow-renderng-with-radeon/.


You have a low-end slow CPU. It's gonna show high load even in general use. Benchmark sites list it as significantly slower than traditional low end CPU's such as Intel I5 5200u.

  • Why it loads when I do web-surfing, but not when I do something more heavy, like playing HD-videos from HDD (then it loads no more than 23%) ? It's 2.5Ghz CPU.
    – R S
    Aug 29, 2018 at 16:14
  • 1
    Probably because video decoding is happening in hardware, whilst the scrolling actually takes up CPU cycles.
    – vidarlo
    Aug 29, 2018 at 16:31
  • "in hardware" sounds too vague, because CPU is hardware too. I tried laptops with 1.4Ghz and less - they were fine. It's somehow related to Xorg process which eats about 50% on scrolling.
    – R S
    Aug 29, 2018 at 18:40
  • 2
    In hardware means that the CPU/GPU has hardware instructions for decoding the video format. This is more efficient than decoding it in software, and the load will not show up in system monitoring utils generally. Clock frequency is a number that says next to nothing about performance, as different CPUs can do different amounts of tasks per clock cycle. A i7 7500 @ 3.5GHz is probably 4-5 times higher performance than a P4 3.8GHz, even though it's clock frequency is lower...
    – vidarlo
    Aug 29, 2018 at 18:50
  • Here is benchmark comparison of my previous and current CPU, isn't AMD more powerful ? cpubenchmark.net/compare/AMD-A6-9220-vs-Intel-Celeron-2957U/…
    – R S
    Aug 31, 2018 at 2:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.