Re: [gentoo-user] Re: Firefox occasionally stalls

[Alan McKinnon]

On 21/03/2017 22:16, Kai Krakow wrote:
> Test one by one... Either disable all, then enable one by one, or
> vice-versa.
>
> Chances are that your FS may be blocking on sync. Do you maybe have a
> very high value in /proc/sys/vm/dirty_background_{ratio,bytes}?
>
> If ratio is 0, then bytes is used. Ratio is a percent of your physical
> RAM. With the default kernel value in modern systems, this is
> ridiculously high for desktop systems. Maybe put a fixed value, like
> 128MB. The dirty background value is the amount of outstanding writes
> before a foreground process blocks on further writes. If this value is
> high, a sync may cause processes to freeze for a long time. Setting
> this to a lower value forces single processes to block early and give
> the kernel a chance to write back dirty data.
>
> The next value to check is dirty_{ratio,bytes}. That is the combined
> maximum of outstanding data before the cache must be flushed. If this
> is hit, all writing processes freeze. So, having the background value
> high gives a greater chance of hitting this early.
>
> The default values are 10% and 20% (ratio). I've made the 20% ratio
> into 10% and put 128MB for background which works quite well:
> Foreground processes are blocked for shorter times (because writing
> 128MB can be a few seconds or less, where 1.6GB can be minutes in a
> worse case, so if overall limit is hit, I'm screwed). The overall
> dirty buffer is still big enough to let the system buffer writes of
> multiple processes. My system has 16GB RAM, you may want to adjust it
> or try different values.
>
> $ cat /etc/sysctl.d/98-caching.conf
> vm.dirty_background_bytes = 134217728
> vm.dirty_ratio = 10
>
> Maybe point your Firefox cache to a tmpfs. If you're using tmpfs, don't
> put swappiness to low, otherwise data sitting in tmpfs cannot be
> swapped out and will cause filesystem caches to be discarded to early.
> I'm working with a 32GB tmpfs and standard swappiness for emerge, and I
> see no problems although multiple gigabytes of emerge build data may be
> swapped out. Still, emerge is so much faster now. But then, my swaps
> are on different disks (and I have multiple for getting some RAID-like
> striping of swap space).
>
> Also, depending on which FS you're using, trying deadline instead of
> CFQ may greatly improve your desktop experience (browsers should
> benefit most from this).


You may be onto something here:

This is an 8-core i7 latop, 16G RAM

$ sudo cat /proc/sys/vm/dirty_background_bytes
0
$ sudo cat /proc/sys/vm/dirty_background_ratio
5
$ sudo cat /proc/sys/vm/dirty_bytes
0
$ sudo cat /proc/sys/vm/dirty_ratio
10

browser cache is on a regular laptop spinning-rust 500G disk

IO scheduler is BFQ, I use it for ages now.
I did tests some years back and found it overall the best for an 
interactive desktop with a DE. I haven't repeated those tests since, has 
there been significant changes in this are last year or three?


-- 
Alan McKinnon
alan.mckinnon@×××××.com