Ah, neat. I noticed that scroll for most (not all) crashes they appeared to be triggered by scroll. I wonder if I’m just imagining it or if we get enough confirmation we should build a proper bug report with reproducible pages / behaviours.
I think it’s worth a bug report. It was often reported (and tortured me for a long time ). I’m really curious what the real underlying problem is.
To my previous post I want to add, that there are more settings in about:config
, that begin with general.smoothScroll.*
and contain some details for what it’s valid. I did set to off all of them.
First, thanks to get this problem solved. It occurs me too. But how to remove the -f ? Little instruction, please?
Open Stock Browser,
enter ‘about:config’ into the browsers address line (without the two ’ )
confirm that you know what you are doing
Then appears a page with abt. 1000 settings, they are sorted alphabetically.
Scroll down to the mentioned field.
Tap into the content field of ‘apz.touch_start_tolerance’ where the f is, set cursor right from the f
Tap backspace once to remove the f
You can also change the number to ‘0.1’
Tap ‘accept’ in the upper right corner of the screen.
Enjoy!
Wow, thanks a lot. Very good hint, made it easy. Seems to be better now. Very nice.
This is a list of all Browser tweaks I’ve made until now to speed up Browser:
I have to confess, this does NOT really solve the Browser crash or memory problem from the root, but crashing happens less often now and it speeds up the browser.
Actually I observe “f” at the end of several numbers in about config, e.g. apz.fling_stopped_threshold, apz.fling_accel_base_mult, apz.min_skate_speed. Are you sure the f is not intentional?
No I’m not sure, and I don’t really know what these settings really mean and in what context they really are with the well known SFOS Browser issues like slowness and the OOM killer issue.
I’m only guessing and trying and hoping I have good luck and find something and removing the f’s I had good luck and it did really bring speed gain. But I have to confess this was not out of real knowledge but only good luck and slowly I get sick of always the same problems of general system instability and self-blocking ‘security’ features of SFOS.
There are dozens of high skilled professional coders involved into the SFOS project and they didn’t make a simple Linux based OS with some simple apps working without permanent need to tweak and bugfix something and there always some bugs and malfunctions remaining that makes SFOS unreliable.
I don’t want to write more to this matter.
It’s probably a lazy programmer thing: I believe it’s a convention to get a higher precision float. That is, to get a 64 bit double instead of a 32 bit float. Why that would be needed in this case is anyone’s guess. In any case, that trailing f is used in java to get a 64 bit Double.
According to: gecko-dev/index.md at 600df6aa643726626d2eab36bc0f6e34bbe5ac2a · sailfishos-mirror/gecko-dev · GitHub
As I don’t see that ‘f’ anywhere in android firefox or desktop one, the conversion should happen automagically, I think this is leftover of how Qt inputs floats there, but it’s probably bening and getting ignored by libpref
EDIT: There are some quite recent bugs relating to parsing floats in preferences but not sure this relates to our version
https://phabricator.services.mozilla.com/D148305
These are two types of routines for handling floats, not from ints but from String. I have to admit, I’m suspicious. Even if you want to sanitize the input, the conversion is, most safely, std::stod in the standard library. Why *aRetVal = ParsePrefFloat(stringVal, &rv);
But then, I’m probably just nitpicking.
The also do stuff like: return 0.f; which is, ok, same as return 0 on most compilers, but, why?!
There’s been some changes in 2019 to allow trailing chars in values ⚙ D42239 Bug 1573648 - Introduce ToDoubleAllowTrailingChars and ToFloatAllowTrailingChars. r?njn
But not sure this AllowTrailingCharsPolicy is used for about:config values (it seems to have been a workaround for a value from html with a trailing slash). These ToDouble/Float are being moved from one place to another multiple times… The changes/reverts from Jun/Dec 2022 are probably not in our gecko, the 2019 bit probably is, but it’s a quagmire
For me, browser crashes always seem to involve videos or images. Watching a video (frequent crashes), scrolling past an image whilst its loading (frequent crashes) or simply just image heavy web pages (less frequent crashes). Mainly text web pages hardly ever crash. Crashes often take other running native apps down as well (greyed out cover pages which then reload the app with a rotating circle) and also daemons as well (which of course you don’t know about until you find something later hasn’t worked).
Its a huge pain and I can’t understand why Jolla didn’t pick this obvious problem up in pre-release testing, especially for 4.5. I had thought that closing other open apps (i.e. Releasing more memory for the browser) might help, but it doesn’t seem to make any difference.
I had a look at the about:config settings and my settings for those mentioned above don’t have any trailing 'f’s - and nobody has tinkered with this setup before so it is as installed from a fresh flash. So not sure why mine are different.
So I started running the tests, current setup is:
- Xperia 10II, build 4.5.0.19
- Using the 4G to access internet (in case that has some influence).
- Browser has 0 active tabs.
- Only open apps are settings and browser.
- Browser is still default config, no change in the about:config.
- I installed Memory watcher | OpenRepos.net — Community Repository System following @karry 's tutorial Sailfish OS and memory :: karry.cz to check my peak memory usage.
I accessed the website Visual Studio Code March 2023 which has a surprising one shot one kill effect and always kills my browser when opened. It’s my first time ever visiting this specific page.
Bellow my “journalctl -f”, i pasted the “full” log here: Framapad annuel
As you can see I open the browser (which previously crashed) at 17:09:13:
Mai 06 17:09:13 Xperia10II-DualSIM dbus-daemon[5957]: dbus-daemon[5957]: [session uid=100000 pid=5957] Activating service name='org.sailfishos.browser.ui' requested by ':1.5520' (uid=100000 pid=25032 comm="/usr/libexec/mliteremoteaction org.sailfishos.brow" label="u:r:kernel:s0")
And 4 seconds later lowmemorykiller
is killing stuff:
Mai 06 17:09:19 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'am.android:mqtt' (24015), adj 905,
to free 47172kB on behalf of 'Cache2 I/O' (25167) because
cache 744468kB is below limit 745120kB for oom_score_adj 529
Mai 06 17:09:19 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'stagram.android' (23854), adj 250,
to free 153008kB on behalf of 'HwBinder:3134_1' (24676) because
cache 652904kB is below limit 652960kB for oom_score_adj 147
Mai 06 17:09:20 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'id.ext.services' (22516), adj 100,
to free 59600kB on behalf of 'Cache2 I/O' (25167) because
cache 560784kB is below limit 560800kB for oom_score_adj 58
Mai 06 17:09:20 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'stagram.android' (25321), adj 0,
to free 46920kB on behalf of 'pool-tracker-mi' (25022) because
cache 464416kB is below limit 468640kB for oom_score_adj 0
Mai 06 17:09:20 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'maliit-server' (20203), adj 0,
to free 54364kB on behalf of 'systemd-journal' (632) because
cache 457108kB is below limit 468640kB for oom_score_adj 0
Mai 06 17:09:20 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'invoker' (25035), adj 0,
to free 2400kB on behalf of 'VideoDecMsgThre' (25313) because
cache 457108kB is below limit 468640kB for oom_score_adj 0
And finally the browser…
Mai 06 17:09:20 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'sailfish-browse' (22258), adj 0,
to free 384508kB on behalf of 'HwBinder:3134_5' (6054) because
cache 456492kB is below limit 468640kB for oom_score_adj 0
At 19:09:07 (so before re-opening the browser after it crashed), my memory was shared between:
Memory at 2023-05-06T17:09:07.194
Memory details: 3.5 GiB total, 48.9 MiB free, 138.5 MiB buffers, 838.0 MiB cached (including 11.2 MiB shmem (tmpfs)), 0 B swap cache
Kernel: 509.8 MiB SLAB (117.7 MiB reclaimable),
~ 1.5 GiB other kernel memory? It means: total - anonymous process - slab - free - buffers - cached - swap cache
Swap: 1024.0 MiB total, 340.2 MiB free (33%)
Available: 1.2 GiB (35%) estimated by kernel
1.1 GiB (32%) computed. It means: free + buffers + (cached - Shmem) + swap cache + slab reclaimable
Processes memory (smaps Pss):
PID process size (% of total) [oom_adj, oom_score, oom_score_adj]
22258 booster [browse 21.6 MiB (1%) [-1000, 0, 0]
7451 tracker-miner-f 15.8 MiB (0%) [-750, 0, 0]
20290 memory-record 14.2 MiB (0%) [-1000, 0, 0]
25008 tracker-extract 9.2 MiB (0%) [-750, 0, 0]
6293 pulseaudio 7.7 MiB (0%) [-750, 0, 0]
6035 xt9-server 6.5 MiB (0%) [-750, 0, 0]
5902 systemd 2.5 MiB (0%) [-750, 0, 0]
5957 dbus-daemon 1.7 MiB (0%) [-750, 0, 0]
6408 dconf-service 1.6 MiB (0%) [-750, 0, 0]
6041 ngfd 1.4 MiB (0%) [-750, 0, 0]
14141 alienkeyboardse 901.0 KiB (0%) [-750, 0, 0]
6687 0 840.0 KiB (0%) [-1000, 0, 0]
14105 alienaudioservi 705.0 KiB (0%) [-750, 0, 0]
7048 booster-browser 417.0 KiB (0%) [-1000, 0, 0]
22545 invoker 388.0 KiB (0%) [-750, 0, 0]
21999 bash 339.0 KiB (0%) [-1000, 0, 0]
15270 bash 332.0 KiB (0%) [-1000, 0, 0]
21727 bash 322.0 KiB (0%) [-1000, 0, 0]
21879 bash 321.0 KiB (0%) [-1000, 0, 0]
6625 mpris-proxy 292.0 KiB (0%) [-750, 0, 0]
6031 profiled 228.0 KiB (0%) [-750, 0, 0]
21816 grep 217.0 KiB (0%) [-1000, 0, 0]
6493 audiosystem-pas 76.0 KiB (0%) [-750, 0, 0]
5954 ohm-session-age 33.0 KiB (0%) [-750, 0, 0]
14174 invoker 26.0 KiB (0%) [-750, 0, 0]
6688 invoker 25.0 KiB (0%) [-750, 0, 0]
6635 invoker 25.0 KiB (0%) [-250, 0, 0]
6220 invoker 24.0 KiB (0%) [-750, 0, 0]
14249 invoker 24.0 KiB (0%) [-750, 0, 0]
6028 invoker 24.0 KiB (0%) [-750, 0, 0]
others 295.0 KiB (0%)
sum 88.1 MiB (2%)
At 17:09:17 (while lowmemorykiller was slaughtering) it was:
Memory at 2023-05-06T17:09:17.192
Memory details: 3.5 GiB total, 18.5 MiB free, 138.9 MiB buffers, 837.1 MiB cached (including 12.1 MiB shmem (tmpfs)), 0 B swap cache
Kernel: 510.0 MiB SLAB (117.8 MiB reclaimable),
~ 1.4 GiB other kernel memory? It means: total - anonymous process - slab - free - buffers - cached - swap cache
Swap: 1024.0 MiB total, 340.5 MiB free (33%)
Available: 1.1 GiB (33%) estimated by kernel
1.1 GiB (31%) computed. It means: free + buffers + (cached - Shmem) + swap cache + slab reclaimable
Processes memory (smaps Pss):
PID process size (% of total) [oom_adj, oom_score, oom_score_adj]
22258 booster [browse 250.1 MiB (7%)
25037 booster [browse 20.8 MiB (1%) [-1000, 0, 0]
7451 tracker-miner-f 15.9 MiB (0%) [-750, 0, 0]
20290 memory-record 14.3 MiB (0%) [-1000, 0, 0]
6293 pulseaudio 7.7 MiB (0%) [-750, 0, 0]
6035 xt9-server 6.5 MiB (0%) [-750, 0, 0]
5902 systemd 2.6 MiB (0%) [-750, 0, 0]
5957 dbus-daemon 1.7 MiB (0%) [-750, 0, 0]
6408 dconf-service 1.6 MiB (0%) [-750, 0, 0]
6041 ngfd 1.4 MiB (0%) [-750, 0, 0]
14141 alienkeyboardse 897.0 KiB (0%) [-750, 0, 0]
6687 0 845.0 KiB (0%) [-1000, 0, 0]
14105 alienaudioservi 702.0 KiB (0%) [-750, 0, 0]
25035 invoker 401.0 KiB (0%)
22545 invoker 366.0 KiB (0%) [-750, 0, 0]
7048 booster-browser 348.0 KiB (0%) [-1000, 0, 0]
21999 bash 339.0 KiB (0%) [-1000, 0, 0]
15270 bash 332.0 KiB (0%) [-1000, 0, 0]
21727 bash 322.0 KiB (0%) [-1000, 0, 0]
21879 bash 321.0 KiB (0%) [-1000, 0, 0]
6625 mpris-proxy 292.0 KiB (0%) [-750, 0, 0]
6031 profiled 228.0 KiB (0%) [-750, 0, 0]
21816 grep 217.0 KiB (0%) [-1000, 0, 0]
6493 audiosystem-pas 76.0 KiB (0%) [-750, 0, 0]
5954 ohm-session-age 33.0 KiB (0%) [-750, 0, 0]
14174 invoker 26.0 KiB (0%) [-750, 0, 0]
6688 invoker 25.0 KiB (0%) [-750, 0, 0]
6635 invoker 25.0 KiB (0%) [-250, 0, 0]
6034 invoker 24.0 KiB (0%) [-750, 0, 0]
6934 invoker 24.0 KiB (0%) [-500, 0, 0]
others 316.0 KiB (0%)
sum 328.5 MiB (9%)
And at 17:09:22 (after the browser crashed) :
Memory at 2023-05-06T17:09:22.195
Memory details: 3.5 GiB total, 237.5 MiB free, 90.9 MiB buffers, 412.4 MiB cached (including 10.3 MiB shmem (tmpfs)), 0 B swap cache
Kernel: 497.9 MiB SLAB (106.9 MiB reclaimable),
~ 1.9 GiB other kernel memory? It means: total - anonymous process - slab - free - buffers - cached - swap cache
Swap: 1024.0 MiB total, 330.7 MiB free (32%)
Available: 882.0 MiB (25%) estimated by kernel
837.4 MiB (24%) computed. It means: free + buffers + (cached - Shmem) + swap cache + slab reclaimable
Processes memory (smaps Pss):
PID process size (% of total) [oom_adj, oom_score, oom_score_adj]
25037 booster [browse 24.6 MiB (1%) [-1000, 0, 0]
7451 tracker-miner-f 15.6 MiB (0%) [-750, 0, 0]
20290 memory-record 14.5 MiB (0%) [-1000, 0, 0]
25341 tracker-extract 9.5 MiB (0%) [-750, 0, 0]
6293 pulseaudio 7.6 MiB (0%) [-750, 0, 0]
6035 xt9-server 6.1 MiB (0%) [-750, 0, 0]
5902 systemd 2.5 MiB (0%) [-750, 0, 0]
5957 dbus-daemon 1.7 MiB (0%) [-750, 0, 0]
6408 dconf-service 1.6 MiB (0%) [-750, 0, 0]
6041 ngfd 1.4 MiB (0%) [-750, 0, 0]
6687 0 844.0 KiB (0%) [-1000, 0, 0]
14141 alienkeyboardse 832.0 KiB (0%) [-750, 0, 0]
14105 alienaudioservi 706.0 KiB (0%) [-750, 0, 0]
7048 booster-browser 423.0 KiB (0%) [-1000, 0, 0]
15270 bash 322.0 KiB (0%) [-1000, 0, 0]
21727 bash 317.0 KiB (0%) [-1000, 0, 0]
21999 bash 317.0 KiB (0%) [-1000, 0, 0]
21879 bash 314.0 KiB (0%) [-1000, 0, 0]
6625 mpris-proxy 292.0 KiB (0%) [-750, 0, 0]
21816 grep 209.0 KiB (0%) [-1000, 0, 0]
6031 profiled 208.0 KiB (0%) [-750, 0, 0]
6493 audiosystem-pas 76.0 KiB (0%) [-750, 0, 0]
5954 ohm-session-age 33.0 KiB (0%) [-750, 0, 0]
6635 invoker 26.0 KiB (0%) [-250, 0, 0]
14174 invoker 26.0 KiB (0%) [-750, 0, 0]
6688 invoker 25.0 KiB (0%) [-750, 0, 0]
6034 invoker 24.0 KiB (0%) [-750, 0, 0]
6037 invoker 24.0 KiB (0%) [-750, 0, 0]
6934 invoker 24.0 KiB (0%) [-500, 0, 0]
6616 invoker 24.0 KiB (0%) [-750, 0, 0]
others 271.0 KiB (0%)
sum 90.3 MiB (3%)
That’s the first information I found, I wonder what steps can I do next so we can get further on this topic ?
This setup is:
- Xperia 10II, build 4.5.0.19
- Using the 4G to access internet (in case that has some influence).
- Browser has 1 active tabs (Visual Studio Code March 2023)
- i disabled android and my emoji keyboard which was spamming the logs when there was a crash.
Full journalctl logs are here: Framapad annuel
By the way, this error:
binder: 2795:2795 transaction failed 29189/-22, size 32-0 line 3096
is when I hold the CTRL key before doing a CTRL + c
In this scenario I closed the browser, ran memory-peak --measurement-time "2023-05-06T17:47:30
before opening:
Memory at 2023-05-06T17:47:07.191
Memory details: 3.5 GiB total, 291.7 MiB free, 16.5 MiB buffers, 423.1 MiB cached (including 3.2 MiB shmem (tmpfs)), 0 B swap cache
Kernel: 444.3 MiB SLAB (84.0 MiB reclaimable),
~ 2.1 GiB other kernel memory? It means: total - anonymous process - slab - free - buffers - cached - swap cache
Swap: 1024.0 MiB total, 504.1 MiB free (49%)
Available: 863.7 MiB (24%) estimated by kernel
812.0 MiB (23%) computed. It means: free + buffers + (cached - Shmem) + swap cache + slab reclaimable
Processes memory (smaps Pss):
PID process size (% of total) [oom_adj, oom_score, oom_score_adj]
7451 tracker-miner-f 15.8 MiB (0%) [-750, 0, 0]
20290 memory-record 13.8 MiB (0%) [-1000, 0, 0]
6293 pulseaudio 8.3 MiB (0%) [-750, 0, 0]
6035 xt9-server 2.9 MiB (0%) [-750, 0, 0]
5902 systemd 2.7 MiB (0%) [-750, 0, 0]
32673 booster [browse 2.7 MiB (0%) [-1000, 0, 0]
5957 dbus-daemon 1.7 MiB (0%) [-750, 0, 0]
6041 ngfd 1.7 MiB (0%) [-750, 0, 0]
6408 dconf-service 1.6 MiB (0%) [-750, 0, 0]
6687 0 827.0 KiB (0%) [-1000, 0, 0]
21999 bash 398.0 KiB (0%) [-1000, 0, 0]
25465 invoker 342.0 KiB (0%) [-750, 0, 0]
7048 booster-browser 302.0 KiB (0%) [-1000, 0, 0]
6625 mpris-proxy 288.0 KiB (0%) [-750, 0, 0]
21727 bash 274.0 KiB (0%) [-1000, 0, 0]
15270 bash 235.0 KiB (0%) [-1000, 0, 0]
21816 grep 198.0 KiB (0%) [-1000, 0, 0]
6031 profiled 177.0 KiB (0%) [-750, 0, 0]
6493 audiosystem-pas 59.0 KiB (0%) [-750, 0, 0]
21879 bash 47.0 KiB (0%) [-1000, 0, 0]
5954 ohm-session-age 33.0 KiB (0%) [-750, 0, 0]
7443 invoker 25.0 KiB (0%) [-750, 0, 0]
6688 invoker 22.0 KiB (0%) [-750, 0, 0]
6037 invoker 22.0 KiB (0%) [-750, 0, 0]
6634 invoker 22.0 KiB (0%) [-500, 0, 0]
6635 invoker 22.0 KiB (0%) [-250, 0, 0]
6934 invoker 21.0 KiB (0%) [-500, 0, 0]
6616 invoker 21.0 KiB (0%) [-750, 0, 0]
6220 invoker 21.0 KiB (0%) [-750, 0, 0]
6028 invoker 21.0 KiB (0%) [-750, 0, 0]
others 155.0 KiB (0%)
sum 54.6 MiB (2%)
Opened the browser at Mai 06 17:47:28 Xperia10II-DualSIM dbus-daemon[5957]: dbus-daemon[5957]: [session uid=100000 pid=5957] Activating service name='org.sailfishos.browser.ui' requested by ':1.5719' (uid=100000 pid=1176 comm="/usr/libexec/mliteremoteaction org.sailfishos.brow" label="u:r:kernel:s0")
It almost loaded the page fully and then:
Mai 06 17:47:38 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'invoker' (1179), adj 0,
to free 2620kB on behalf of 'sailfish-browse' (32673) because
cache 103916kB is below limit 468640kB for oom_score_adj 0
Mai 06 17:47:38 Xperia10II-DualSIM kernel: lowmemorykiller: Killing 'sailfish-browse' (32673), adj 0,
to free 567648kB on behalf of 'threaded-ml' (1398) because
cache 103916kB is below limit 468640kB for oom_score_adj 0
Memory peak at 17:47:37.199 (so when the browser page was loading) shows:
Memory at 2023-05-06T17:47:37.199
Memory details: 3.5 GiB total, 45.3 MiB free, 7.3 MiB buffers, 176.4 MiB cached (including 5.2 MiB shmem (tmpfs)), 0 B swap cache
Kernel: 442.3 MiB SLAB (81.0 MiB reclaimable),
~ 2.2 GiB other kernel memory? It means: total - anonymous process - slab - free - buffers - cached - swap cache
Swap: 1024.0 MiB total, 498.7 MiB free (49%)
Available: 260.9 MiB (7%) estimated by kernel
304.9 MiB (9%) computed. It means: free + buffers + (cached - Shmem) + swap cache + slab reclaimable
Processes memory (smaps Pss):
PID process size (% of total) [oom_adj, oom_score, oom_score_adj]
32673 booster [browse 604.8 MiB (17%)
1181 booster [browse 18.1 MiB (1%) [-1000, 0, 0]
20290 memory-record 14.0 MiB (0%) [-1000, 0, 0]
7451 tracker-miner-f 13.6 MiB (0%) [-750, 0, 0]
6293 pulseaudio 9.2 MiB (0%) [-750, 0, 0]
5902 systemd 2.4 MiB (0%) [-750, 0, 0]
5957 dbus-daemon 1.7 MiB (0%) [-750, 0, 0]
6408 dconf-service 1.6 MiB (0%) [-750, 0, 0]
6041 ngfd 1.4 MiB (0%) [-750, 0, 0]
6035 xt9-server 1.3 MiB (0%) [-750, 0, 0]
6687 0 862.0 KiB (0%) [-1000, 0, 0]
1179 invoker 366.0 KiB (0%)
21999 bash 357.0 KiB (0%) [-1000, 0, 0]
25465 invoker 339.0 KiB (0%) [-750, 0, 0]
6625 mpris-proxy 288.0 KiB (0%) [-750, 0, 0]
21727 bash 252.0 KiB (0%) [-1000, 0, 0]
15270 bash 235.0 KiB (0%) [-1000, 0, 0]
7048 booster-browser 232.0 KiB (0%) [-1000, 0, 0]
21816 grep 197.0 KiB (0%) [-1000, 0, 0]
6031 profiled 177.0 KiB (0%) [-750, 0, 0]
6493 audiosystem-pas 57.0 KiB (0%) [-750, 0, 0]
21879 bash 47.0 KiB (0%) [-1000, 0, 0]
5954 ohm-session-age 31.0 KiB (0%) [-750, 0, 0]
7443 invoker 23.0 KiB (0%) [-750, 0, 0]
6634 invoker 22.0 KiB (0%) [-500, 0, 0]
6635 invoker 22.0 KiB (0%) [-250, 0, 0]
6688 invoker 21.0 KiB (0%) [-750, 0, 0]
6028 invoker 21.0 KiB (0%) [-750, 0, 0]
6034 invoker 21.0 KiB (0%) [-750, 0, 0]
6616 invoker 21.0 KiB (0%) [-750, 0, 0]
others 191.0 KiB (0%)
sum 671.9 MiB (19%)
Hi all. Is here some guru who knows Linux memory management? I’m author of memory watcher tool, I read many sources about memory, but still cannot say properly how available memory is distributed. Problem for me is this computation: anonymous memory of user-space processes + slab + free value + buffers + caches + swap cache is usually less than total system memory. What allocator owns it? Do I overlook some value?
It’s a lot of work, but when analyzing memory usage in the past, I’ve used pidstat for pid level memory usage logging. It’s in the systat packages, usually. I did run it on SFOS. pidstat(1) - Linux manual page
I found something new that seems to help:
apz.autoscroll.enabled: off
apz.disable_for_scroll_linked_effects: on
edit: browser.cache.disk.max_entry_size: 4096 → 1024
I can’t imagine that a max. entry size of 4096 is good while the cache has only 1024 in size by default.
feedback is very welcome!
I’m trying that tomorrow, and also your tip from the other thread
Does anyone have an idea how we can benchmark this? maybe select a few sites and do a few testruns from a clean state?
If we had a testprotocol, we could get an objective insight into what acutally helps.