Did anyone try proposing changes to the actual upstream Linux default instead of just hacking it higher downstream? Doesn't look like it's even configurable at the moment, based on the Fedora document. Martin On Mon, Mar 25, 2024 at 5:08 PM Rein Fernhout (Levitating) <me@xxxxxxxxxxx> 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
