Proposal to increase the default vm.max_map_count value
Hi everyone, I'm writing this mail as proposal to increase the default `vm.max_map_count` [1] value in Arch Linux. The default `vm.max_map_count` 65530 value is making some Windows games crash (or even prevent them to start at all) while being played through Wine or Steam Play (Proton). Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to Valve for these games on that matter). In that regard, SteamOS is shipping an increased `vm.max_map_count` default value to address the above issue and numerous distributions have since then decided to implement that change on their side as well, such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5]. While I'm aware that Arch is a user centric/DIY distro and everyone can 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). In terms of implementation, the change basically consists of shipping the following sysctl file: ``` # Increase the number of virtual memory areas that one process may request vm.max_map_count=1048576 ``` For reference, Fedora added it to their systemd package [6], while Ubuntu handled it at the procps level [7]. I personally don't have a strong opinion on the implementation way/place. To sum up, I think this would be a reasonable and positive change to make to our distro. I'd be happy to read your thoughts (or eventual objection)! 😊 [1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount [4] https://github.com/NixOS/nixpkgs/pull/238459 [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 [6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf [7] https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4-4ubuntu2&id=b4a4a046cf018a942598e55f3fbc7b5ef474f676 -- Regards, Robin Candau / Antiz
On 25.03.24 09:10, Robin Candau wrote:
Hi everyone,
I'm writing this mail as proposal to increase the default `vm.max_map_count` [1] value in Arch Linux.
The default `vm.max_map_count` 65530 value is making some Windows games crash (or even prevent them to start at all) while being played through Wine or Steam Play (Proton). Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to Valve for these games on that matter).
In that regard, SteamOS is shipping an increased `vm.max_map_count` default value to address the above issue and numerous distributions have since then decided to implement that change on their side as well, such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5].
While I'm aware that Arch is a user centric/DIY distro and everyone can 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).
In terms of implementation, the change basically consists of shipping the following sysctl file:
``` # Increase the number of virtual memory areas that one process may request vm.max_map_count=1048576 ```
For reference, Fedora added it to their systemd package [6], while Ubuntu handled it at the procps level [7]. I personally don't have a strong opinion on the implementation way/place.
To sum up, I think this would be a reasonable and positive change to make to our distro. I'd be happy to read your thoughts (or eventual objection)! 😊
[1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount [4] https://github.com/NixOS/nixpkgs/pull/238459 [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 [6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf [7] https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4-4ubuntu2&id=b4a4a046cf018a942598e55f3fbc7b5ef474f676
Nice idea, I'm in favour. This has actually bitten me before. If other distros have this, users will come to expect it as the defacto default and would be confused if Arch behaved differently. I'm curious: At this point, I think we have a good case to try to get this changed upstream. Has this been attempted?
On 3/25/24 1:49 PM, Sven-Hendrik Haase wrote:
On 25.03.24 09:10, Robin Candau wrote:
Hi everyone,
I'm writing this mail as proposal to increase the default `vm.max_map_count` [1] value in Arch Linux.
The default `vm.max_map_count` 65530 value is making some Windows games crash (or even prevent them to start at all) while being played through Wine or Steam Play (Proton). Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to Valve for these games on that matter).
In that regard, SteamOS is shipping an increased `vm.max_map_count` default value to address the above issue and numerous distributions have since then decided to implement that change on their side as well, such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5].
While I'm aware that Arch is a user centric/DIY distro and everyone can 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).
In terms of implementation, the change basically consists of shipping the following sysctl file:
``` # Increase the number of virtual memory areas that one process may request vm.max_map_count=1048576 ```
For reference, Fedora added it to their systemd package [6], while Ubuntu handled it at the procps level [7]. I personally don't have a strong opinion on the implementation way/place.
To sum up, I think this would be a reasonable and positive change to make to our distro. I'd be happy to read your thoughts (or eventual objection)! 😊
[1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount [4] https://github.com/NixOS/nixpkgs/pull/238459 [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 [6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf [7] https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4-4ubuntu2&id=b4a4a046cf018a942598e55f3fbc7b5ef474f676
Nice idea, I'm in favour. This has actually bitten me before. If other distros have this, users will come to expect it as the defacto default and would be confused if Arch behaved differently.
Hi Sven, Thanks for your input! I agree.
I'm curious: At this point, I think we have a good case to try to get this changed upstream. Has this been attempted?
Yes, it has been brought to upstream's attention recently [1]. No answer yet though. Although, I'm wondering if this change will be considered on upstream side just yet. I'm afraid it will be seen a "distribution matter" rather than a "linux kernel" one currently, regarding the fact that the related issue is kinda specific for now (it's mostly an issue when playing modern Windows games with Wine or Steam at the moment, although I've seen similar reported issues for other "regular" resource intensives applications). But I could be wrong, obviously. However, I think that "following the tendance" by implementing that change on our side (as other distros already did) would work toward making this "a classic", eventually getting users expecting it as the defacto default (as you said). If, at some point, every major distros are making that change on their side, I think that would be a legitimate/reasonable reason to bring it back to upstream's attention and ask for a revision of that value to fit current standards (in the event that they do not consider it right now). So, regardless of upstream thoughts on this at the moment, I feel like "joining the movement" on our side would be beneficial, both right now and to lean toward an eventual future adoption of that change on upstream side. [1] https://lore.kernel.org/lkml/566168554.272637693.1710968734203.JavaMail.root... -- Regards, Robin Candau / Antiz
-------- Original Message -------- On 3/25/24 4:10 AM, Robin Candau <antiz@archlinux.org> wrote:
Hi everyone,
I'm writing this mail as proposal to increase the default `vm.max_map_count` [1] value in Arch Linux.
The default `vm.max_map_count` 65530 value is making some Windows games crash (or even prevent them to start at all) while being played through Wine or Steam Play (Proton). Examples are (but not limited to) Star Citizen, THE FINALS, Hogwarts Legacy, DayZ or Counter-Strike 2 (see [2] for a list of bug reported to Valve for these games on that matter).
In that regard, SteamOS is shipping an increased `vm.max_map_count` default value to address the above issue and numerous distributions have since then decided to implement that change on their side as well, such as Fedora [3], NixOS [4] and, more recently, Ubuntu [5].
While I'm aware that Arch is a user centric/DIY distro and everyone can 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).
In terms of implementation, the change basically consists of shipping the following sysctl file:
``` # Increase the number of virtual memory areas that one process may request vm.max_map_count=1048576 ```
For reference, Fedora added it to their systemd package [6], while Ubuntu handled it at the procps level [7]. I personally don't have a strong opinion on the implementation way/place.
To sum up, I think this would be a reasonable and positive change to make to our distro. I'd be happy to read your thoughts (or eventual objection)! 😊
[1] https://docs.kernel.org/admin-guide/sysctl/vm.html#max-map-count [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792/comments/5 [3] https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount [4] https://github.com/NixOS/nixpkgs/pull/238459 [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 [6] https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf [7] https://git.launchpad.net/ubuntu/+source/procps/commit/?h=applied/2%254.0.4-4ubuntu2&id=b4a4a046cf018a942598e55f3fbc7b5ef474f676
-- Regards, Robin Candau / Antiz
As stated on Matrix, I am in favor of this change. Though Arch is indeed a distribution for tinkerers, of course, this change sets up a reasonable default that saves time for each tinkerer who just wants their favorite games to work properly. Given that other distributions that tend towards more conservative approaches to defaults changes are implementing this, it should be a safe change to make. Campbell
On 3/25/24 9:10 AM, Robin Candau wrote:
Hi everyone,
I'm writing this mail as proposal to increase the default `vm.max_map_count` value in Arch Linux.
It's been a week since this proposal thread [1] was made. For now it only received a few but all positives feedback (both from staff members and users in a related thread on arch-general [2]). Do we have any more thoughts anyone wants to share? Also, if we are to implement this change, anyone has an opinion about which package should provide it? So far, the following packages have been mentioned: - systemd (as Fedora did) - procps-ng (as Ubuntu did) - filesystem Given that the proposal goes through, I'll create the MR to the chosen package accordingly. Also, despite this change being impact-free (as far as we can tell), I think a related news item to inform users about this change would be a great idea (I'll write that as well). Please, share your opinion about the change itself or the best package to provide it if you have any :) [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [2] https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/t... -- Regards, Robin Candau / Antiz
participants (3)
-
arch＠serebit.com
-
Robin Candau
-
Sven-Hendrik Haase