Thank you for your donation!


Version 5 - CPU over 200%, slow interface
#31
The fix works perfectly on my test system. You may need to open System config and Clear local UI browser cache, then Refresh the Browser on the Touch display to force chromium to load the updated css.

According to the article it forces the Browser to use Hardware (GPU) rendering instead of Software (CPU) rendering for keyframe animations. https://stackoverflow.com/questions/1317...e-this-way

- Pi-3B
- Pi 7" Touch
- moOde 5.2
- Kernel 4.19.46-v7+
- Chromium 72.0.3626.121 Built on Raspbian , running on Raspbian 9.9

Heres are snapshots of top and moodeutl -m with CoverView animated backdrop running. Max CPU util ~ 10%

Code:
top -H -p `pidof chromium-browser-v7`

top - 07:35:48 up 17:14,  1 user,  load average: 0.72, 0.49, 0.40
Threads:  29 total,   0 running,  29 sleeping,   0 stopped,   0 zombie
%Cpu0  :  3.9 us,  0.0 sy,  0.0 ni, 96.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  8.9 us,  1.4 sy,  0.0 ni, 89.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  1.4 us,  0.0 sy,  0.0 ni, 98.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 10.8 us,  1.4 sy,  0.0 ni, 87.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   948300 total,   168740 free,   205412 used,   574148 buff/cach
KiB Swap:        0 total,        0 free,        0 used.   579824 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
1246 pi        20   0  542804 137768 102048 S 12.3 14.5  80:14.61 chromium-browse
1389 pi        20   0  542804 137768 102048 S  1.3 14.5  13:07.57 Chrome_IOThread
1255 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 sandbox_ipc_thr
1383 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 chromium-browse
1384 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.21 TaskSchedulerSe
1385 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.39 TaskSchedulerFo
1388 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 inotify_reader
1471 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 llvmpipe-0
1472 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 llvmpipe-1
1473 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 llvmpipe-2
1474 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 llvmpipe-3
1477 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 NetworkChangeNo
1478 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 Bluez D-Bus thr
1479 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 CrShutdownDetec
1484 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.03 CompositorTileW
1485 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.03 AudioThread
1487 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.01 TaskSchedulerSi
1488 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.68 CacheThread_Blo
1489 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.01 TaskSchedulerSi
1490 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 gpu-process_cra
1492 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 BrowserWatchdog
1666 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.01 TaskSchedulerSi
1667 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.15 Chrome_HistoryT
1679 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 TaskSchedulerSi
1682 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 renderer_crash_
1696 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 extension_crash
2321 pi        20   0  542804 137768 102048 S  0.0 14.5   0:04.54 TaskSchedulerFo
4328 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 utility_crash_u
19597 pi        20   0  542804 137768 102048 S  0.0 14.5   0:00.00 TaskSchedulerFo

Code:
pi@rp5:~ $ moodeutl -m
CPU: 600 MHz | LOAD: 11% | TEMP: 49°C | RAM_USED: 41% | DISK_USED: 78% | FPM_POOL: 15 workers
Reply
#32
(05-29-2019, 12:00 PM)Tim Curtis Wrote: - Pi-3B
- Pi 7" Touch
- moOde 5.2
- Kernel 4.19.46-v7+
- Chromium 72.0.3626.121 Built on Raspbian , running on Raspbian 9.9
Hi Tim,
I noticed your Kernel is 4.19.46.
The one that comes with 5.2 is 4.19.40 and if I do an update to the "latest" it only goes to 4.19.42
Still, with 5.2 and any Kernel (don't know how to install 4.19.46), the system still runs the CPU between 180% and 220% (even with Pure Black Selected).
Looks like the only way to get the readings you do on my system is for it to be on V5.0 with the 4.19.42 Kernel.
The system is unusable otherwise.
Rob
Reply
#33
@rb0135

Are you sure you cleared the Local Display browser cache (in the Configure>System panel) after applying the patch?

Tim came up with the patch in discussion on the Test Team forum. I tried it on a stock moOde r5.2 system and thought it didn't work until I realized I hadn't cleared cache. <proving that no one is immune from seemingly rookie mistakes!>

With the patch applied, the CompositorTileW threads drop from nearly 100% CPU usage to less than 1%.

Sample top -H output:

Code:
top - 07:52:59 up 19:17,  1 user,  load average: 0.08, 0.21, 0.20
Threads: 208 total,   3 running, 159 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5.7 us,  2.5 sy,  0.0 ni, 91.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   948304 total,   409980 free,   149468 used,   388856 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   692048 avail Mem

 PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                      
1408 pi        20   0  386908  96148  61064 R  5.0 10.1  60:19.08 chromium-browse                              
1170 pi        20   0  512812 119100  98784 S  3.3 12.6  51:17.12 chromium-browse                              
1596 pi        20   0  386908  96148  61064 S  2.6 10.1  36:58.71 Compositor                                    
31275 pi        20   0    8240   3144   2660 R  1.0  0.3   0:00.11 top                                          
1141 root      20   0  125872  29804  21412 S  0.7  3.1  11:30.65 Xorg                                          
1190 pi        20   0  512812 119100  98784 S  0.7 12.6   9:39.26 Chrome_IOThread                              
1413 pi        20   0  386908  96148  61064 S  0.7 10.1   6:50.63 Chrome_ChildIOT                              
 525 root      20   0  189344  12240   8768 S  0.3  1.3   2:09.64 worker.php                                    
1597 pi        20   0  386908  96148  61064 S  0.3 10.1   7:22.56 CompositorTileW                              
1598 pi        20   0  386908  96148  61064 S  0.3 10.1   7:25.07 CompositorTileW


This is with kernel 4.19.40-v7+

Regards,
Kent
Reply
#34
Kent/Tim,

I wasn't clearing cache, I missed Tim's mention of that. I was just restarting the Pi after the change. DOH

I have started afresh with V5.2 image (using the kernel that came with the V5.2 image), set it all up, then did the change from Tim's post and cleared the cache.

Well, it does somewhat fix it on my rig.

It now reports CPU usage between 20-30% (not playing any audio) which I thought I would live with, BUT, every 20 secs or so, when I do play the audio drops out for 1-2 secs then comes back on. This is one of my original issues I had with V5.2.

If I put back in the V5.0 with latest Kernel, I don't have that audio issue (I have 2 SD cards, same type, speed, etc, so easy to test. Moode config the same such as buffer before play settings, etc).

I see V5.3 is in the making, so I will just live with what I have and test that version.

Certainly, Tim's CSS fix did change the behaviour (once I cleared the cache).

Thanks,
Rob
Reply
#35
I'm using a couple of different Android tablets as the UI although I've done some testing with my desktop machine.  V 5.3 is a bit speedier on the tablets than 5.2 but there is often a significant (20 to 30 second) lag between tapping the screen and getting a response.  The problem is intermittent.  Makes me wonder if caching is involved.  When I've tried it on the desktop things go normally.  Response time is fine.  The desktop machine has 16 gig of RAM and a big swap file.  The tablets, strangely enough, have smaller processors, less RAM, and less storage.  <g>  On the tablets the problem occurs when the only thing in the task swap space other than the OS is the browser.  On the tablets I've tried Chrome, Brave, and Firefox.  On the Windows machine Win 10 I normally use Chrome.
Reply


Forum Jump: