On 3/25/24 5:48 PM, Martin Rys wrote:

Did anyone try proposing changes to the actual upstream Linux default instead of just hacking it higher downstream? Yes, see this message [1] from the original thread in the Arch-Dev-Public ML. Although, I personally doubt that upstream will consider this change at the moment, but I could be wrong.

Doesn't look like it's even configurable at the moment, based on the Fedora document. Not sure what you mean or what you are referring to? Of course the vm.max_map_count value is configurable.

Martin

On Mon, Mar 25, 2024 at 5:08 PM Rein Fernhout (Levitating) wrote:

...

Seeing as other distributions have already adopted this change and gaming is a popular usecase for ArchLinux I do think this is a good thing to have. The default value will only be more of a bottleneck in the future.

There's a balance in sticking to defaults. It'd be a shame if users need to alter multiple kernel parameters just to play modern games or run other applications with a high memory footprint.

As I understand it there's no real downside to increasing this. Could someone with more knowledge of the kernel shed some light on any possible adverse effects that might come from increasing the default?

I am also curious how the upstream discussed will go but I do not expect them to change it.

Cheers, Levitating

On 2024-03-25 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

[1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... -- Regards, Robin Candau / Antiz