Nice to see more Linux distributions make changes to ensure the gaming experience is good. Arch Linux is now following Fedora and Ubuntu on upping the vm.max_map_count value.
The issue is the default from the upstreaming Linux kernel is just too low for some games like The Finals, Hogwarts Legacy, DayZ, Counter-Strike 2 and various others causing them to crash. Not a good experience for end-users.
Announced in an official news post:
The vm.max_map_count paramater will be increased from the default
65530
value to1048576
.This change should help address performance, crash or start-up issues for a number of memory intensive applications, particularly for (but not limited to) some Windows games played through Wine/Steam Proton. Overall, end users should have a smoother experience out of the box with no expressed concerns about potential downsides in the related proposal on arch-dev-public mailing list.
This
vm.max_map_count
increase is introduced in the2024.04.07-1
release of the filesystem package and will be effective right after the upgrade.Before upgrading, in case you are already setting your own value for that parameter in a
sysctl.d
configuration file, either remove it (to switch to the new default value) or make sure your configuration file will be read with a higher priority than the/usr/lib/sysctl.d/10-arch.conf
file (to supersede the new default value).
Want to know what your current value is? You can run this in terminal cat /proc/sys/vm/max_map_count
If you want to test a different value, in terminal you can run sudo sysctl -w vm.max_map_count=1048576
which will persist until a reboot.
65530
Why am I hearing about it just now?
Edit: I added it a year ago, from https://www.phoronix.com/news/Fedora-39-VM-Max-Map-Count.
Last edited by fabertawe on 8 April 2024 at 8:47 am UTC
I run EndeavourOS.
BTW why is default 65530 and not a round number like 65536?
Probably the structure holding those takes some extra space for 'bookkeeping'. In such case allocating exactly 65536 entries would require some number of full memory pages and a few bytes on another page that would be mostly empty, which would be inefficient.
xpander@archlinux ~ $ cat /etc/sysctl.d/80-gamecompatibility.conf
vm.max_map_count = 2147483642
Last edited by Xpander on 14 April 2024 at 7:23 am UTC
So for those of us who don't know, what would upping this actually help with, and how would one know if one was running into problems with it in the first place?
I believe the game just CTD's as it needs more memory than the system allows for.
Example case:
https://steamcommunity.com/app/990080/discussions/0/3761104682797572808/
So for those of us who don't know, what would upping this actually help with, and how would one know if one was running into problems with it in the first place?
I believe the game just CTD's as it needs more memory than the system allows for.
Example case:
https://steamcommunity.com/app/990080/discussions/0/3761104682797572808/
It's not about needing more memory, but needing more memory mappings. It's kind of similar to the file descriptor count number that became an issue when esync became a thing. Over time, software/games just need more of them as they have more uses. If the system doesn't allow for more, a process just crashes. Most of those defaults were set long ago and don't reflect current times.
Considering this is Arch, shouldn't these users already know or at least be doing this themselves? I mean they do call themselves the geeks of Linux after all...
The question was already addressed when the proposal was submited:
While I'm aware that Arch is a user centric/DIY distro and everyone canSource (linked in the article): https://lists.archlinux.org/archives/list/[email protected]/thread/5GU7ZUFI25T2IRXIQ62YYERQKIPE3U6E/
set their own `vm.max_map_count` value fairly easily, shipping an
increased value on our side would be a beneficial change to make in my
opinion as it would result in a smoother gaming experience out of the
box for our users without representing any downside/side effect (as far
as I'm aware).
Just because you can configure something doesn't mean you have to leave a crappy default value.
Given that many distros make this change, we can also expect it to become the kernel default in the future (special cases such as embedded will then be the ones who have to reconfigure it).
Last edited by Breizh on 10 April 2024 at 11:57 am UTC
See more from me