mobile intel wifi & bluetooth problem on Linux

If you have frequent wifi instability with Wifi on this device:
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

(or, more specificallly):

[   17.718800] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210

... and in dmesg you can see some microcode crash reporting every now and then, try disabling bluetooth coexistence by passing some options to iwlwifi module:

options iwlwifi  bt_coex_active=N

(I also have power_save=y 11n_disable=8 but IMMV so try the above alone first).

It seems that altought the bluetooth device *is made by intel and built into the same card*, they don't play along - using bluetooth coexistence signaling makes the wifi defers transmission and probably some timeout leads to a crash - perhaps it's an aggressive watchdog that intel itself left enabled.

Anyway, I now have stable wifi.

Cheers.

BTW in debian/ubuntu what you'd do is this:

# /etc/modprobe.d/iwlwifi.conf

options iwlwifi bt_coex_active=N # power_save=y 11n_disable=8 

# iwlwifi will dyamically load either iwldvm or iwlmvm depending on the

# microcode file installed on the system.  When removing iwlwifi, first

# remove the iwl?vm module and then iwlwifi.

remove iwlwifi \

(/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs /sbin/rmmod) \

&& /sbin/modprobe -r mac80211

SSD, Linux and /proc/sys/vm/vfs_cache_pressure

In pretty much every "here is what you should do to optimize Linux in your flash new SSD" guide you can find someone comes with something like this:

"You should tune /proc/sys/vm/vfs_cache_pressure and lower from the default 100 to 50 or something" (and btw setting vm.vfs_cache_pressure  = 50 in /etc/sysctl.conf is fastest permanent way of doing that).


It seems like everyone took the copy-and-past route on the first guy who wrote those lines.

I beg to differ.

The thing is: if you can afford the ram and you have a slow (rotionary disk), it makes every sense in the world to significantly lower vfs_cache_pressure because on doing so you're telling the kernel that it should prefer to discard other caches before vfs when there's memory pressure. Otherwise, something simple as a find | xargs grep (or the simply the find itself) can take huge amount of time to traverse directories, etc.

But if you have a 500 Mb/s SSD disk with outstanding random-access times, it's less so. Remember, every other knob remaining on it's defaults,  the caches are only flushed when there's ram pressure. And although ram is way faster than ssd, you could be trading a lot of it for a best-case of milliseconds over microseconds, while on the rotational case the relationship is more of seconds for milliseconds and so more perceivable.

On most workloads, you can still benefit from lowering vfs_cache_pressure a bit (say to 90 from it's original 100), but don't go as far as you would with a conventional hard drive for there's little point in doing so. Unless copying huge files/directories around is your work and you have the ram for it, then by all means go for it.

Everyone else should benchmark it before taking for granted. You're welcome.