Re: Proposal to increase the default vm.max_map_count value
On Tue, 2024-04-02 at 12:29 +0200, Robin Candau wrote: > On 4/2/24 11:59 AM, Robin Candau wrote: Couple of comments. * In lkml thread on same topic not everyone is on board with this [1] * Where to put this kind of thing Would it make sense to collect these kind of "system" settings, that dont clearly belong to a specific application, into a separate package (arch-system-settings or whatever). Admittedly at moment this would be very small package [1] https://lkml.org/lkml/2024/4/2/404 -- Gene signature.asc Description: This is a digitally signed message part
Re: Proposal to increase the default vm.max_map_count value
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=b4a4a046cf018a942598e55f3fbc7b5ef474f676 [1] https://lists.archlinux.org/archives/list/arch-dev-pub...@lists.archlinux.org/message/SCAEAR7JYDAMDBMQYU2PGYFEW3BM235V/ -- Regards, Robin Candau / Antiz OpenPGP_0xFDC3040B92ACA748.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Proposal to increase the default vm.max_map_count value
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) 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=b4a4a046cf018a942598e55f3fbc7b5ef474f676
Re: Proposal to increase the default vm.max_map_count value
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=b4a4a046cf018a942598e55f3fbc7b5ef474f676
