Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On Wed, Apr 26, 2023 at 07:42:44AM -0500, Michael Catanzaro wrote: > On Wed, Apr 26 2023 at 08:50:51 AM +0200, Vitaly Zaitsev via devel > wrote: > >If needed by Steam or Wine, they should provide a .conf file instead > >rather than changing this setting system wide. > Problem is this doesn't work for containers Also, is that a global change? Generally we _shouldn't_ drop in overall system configuration via individual packages. It leads to surprising results and is hard to diagnose. (Oh! You are getting the OOM killer because you happen to have steam installed, even though it's not running...) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On 4/26/23 08:50, Vitaly Zaitsev via devel wrote: On 24/04/2023 18:12, Ben Cotton wrote: This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. AFAIK, a small number is a security measure. Memory mappings are kernel level objects, so poorly written applications can easily exhaust the limit of the entire system and make it unusable. If needed by Steam or Wine, they should provide a .conf file instead rather than changing this setting system wide. Steam from the RPM Fusion repository is already changing the DefaultLimitNOFILE variable: https://github.com/rpmfusion/steam/blob/master/01-steam.conf The right question is: is there a value that is high enough for apps (including Steam) and low enough to not be a security danger? I mean from 65530 to 2billion there is a lot of middle ground. How much does Steam really need? (somebody can check the stats while running it) How much is needed to crash a system? In general I find all these limits (maxopenfiles, maxprocs, ...) very annoying, they always assume my system is a toy and if I want to "do real stuff" I have to remove the side wheel of the bicycle myself. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On Wed, Apr 26 2023 at 08:50:51 AM +0200, Vitaly Zaitsev via devel wrote: If needed by Steam or Wine, they should provide a .conf file instead rather than changing this setting system wide. Problem is this doesn't work for containers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On 24/04/2023 18:12, Ben Cotton wrote: This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. AFAIK, a small number is a security measure. Memory mappings are kernel level objects, so poorly written applications can easily exhaust the limit of the entire system and make it unusable. If needed by Steam or Wine, they should provide a .conf file instead rather than changing this setting system wide. Steam from the RPM Fusion repository is already changing the DefaultLimitNOFILE variable: https://github.com/rpmfusion/steam/blob/master/01-steam.conf -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
Peter Boy kirjoitti 25.4.2023 klo 1.29: The increase step looks very massive. And I wonder why we should make such a change to make games of all things work out of the box. Are games the main use case of Fedora? I do not think there is *the* main use case for Fedora. But certainly, games are *a* use case that many users do care about, including me. Making them work better is important. Wouldn't it make more sense to create a game spin instead? After all, we already have a Lab. Or make a corresponding change in this context. Games should work well on Fedora Workstation. Playing games is even a use case listed in the Fedora Workstation PRD [1]. [1]: https://docs.fedoraproject.org/en-US/workstation-working-group/prd/ Otherwise, I have no expertise to comment on the proposed change. Luckily, we already have some knowledgeable replies from those others. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On 4/25/23 1:34 PM, Neal Gompa wrote: Maybe we can talk to the folks in the Wine community about what we should do to support their needs better within Fedora? If we don't want to go to the max (ish), maybe we can find a middle ground that makes games work on Fedora better. I agree. While Valve is doing a great job they're also keeping themselves isolated more than I know we'd all like. I think a compromise could be made between Wine and the kernel folks on what the best action is to take. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On Tue, Apr 25, 2023 at 1:59 PM Matthew Miller wrote: > > On Mon, Apr 24, 2023 at 05:07:53PM -0400, JT wrote: > > How this would affect memory performance on a workstation or server with > > much more running concurrently, is something I can't really speak to, but I > > would guess there's a point where increasing it could cause issues > > depending on total memory available and how many processes are getting > > memory reservations from the kernel. > > For what it's worth, our friends over at SUSE have a kbase article on the > possible side-effects of increasing this setting. Find it at > https://www.suse.com/support/kb/doc/?id=16692. (In short, the > consequences are that processes which map more memory can do so, which is > bad for memory usage overall and can hurt performance.) > Maybe we can talk to the folks in the Wine community about what we should do to support their needs better within Fedora? If we don't want to go to the max (ish), maybe we can find a middle ground that makes games work on Fedora better. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
On Mon, Apr 24, 2023 at 05:07:53PM -0400, JT wrote: > How this would affect memory performance on a workstation or server with > much more running concurrently, is something I can't really speak to, but I > would guess there's a point where increasing it could cause issues > depending on total memory available and how many processes are getting > memory reservations from the kernel. For what it's worth, our friends over at SUSE have a kbase article on the possible side-effects of increasing this setting. Find it at https://www.suse.com/support/kb/doc/?id=16692. (In short, the consequences are that processes which map more memory can do so, which is bad for memory usage overall and can hurt performance.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
* Ben Cotton:
> Concerns over possible downsides were raised. I am not aware of any,
> but more input here is desired.
You can play with the following program to overload the kernel with many
mappings:
#include
#include
#include
#include
#include
int
main (int argc, char **argv)
{
int count;
if (argc != 2 || (count = atoi (argv[1])) < 1) {
fprintf (stderr, "usage: %s PAGE-COUNT\n", argv[0]);
return 1;
}
long page_size = sysconf (_SC_PAGE_SIZE);
size_t total_size;
if (__builtin_mul_overflow (page_size, count, _size))
errx (1, "page count too large: %d", count);
void *p = mmap (NULL, total_size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS,
-1, 0);
if (p == MAP_FAILED)
err (1, "mmap (%zu bytes)", total_size);
char *p0 = p;
for (unsigned i = 0; i < (unsigned) count; i += 2) {
if (mprotect (p0, page_size, PROT_READ | PROT_WRITE) != 0)
err (1, "mprotect (after %u mappings)", i);
p0 += 2 * page_size;
}
}
In my experiments, the kernel OOM handler does not terminate this
mapping-creating process, but random desktop services first. If the
stress tester runs directly under GNOME Terminal, it may get terminated
early enough for the desktop to recover (with some services missing,
like calendar and tracker). But if it runs under tmux in the background
(still as non-root), it either crashes or freezes the desktop.
This was with kernel 6.2.9-200.fc37.x86_64.
So I would like to echo the suggestion that this should go upstream
first, along with some OOM handler improvements.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
Once upon a time, Ben Cotton said: > Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up > from `65530` of Fedora; it makes sense to follow their lead and set > the same value. It doesn't necessarily make sense for a general-purpose OS to follow what is effectively an embedded platform. If this is a good change with no downsides, then how about going "upstream first" and getting the change into the Linux kernel? If this is just for Steam games, then how about seeing if the RPMFusion Steam package can include this as a sysctl.d drop-in? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
The increase step looks very massive. And I wonder why we should make such a change to make games of all things work out of the box. Are games the main use case of Fedora? Wouldn't it make more sense to create a game spin instead? After all, we already have a Lab. Or make a corresponding change in this context. > Am 24.04.2023 um 23:07 schrieb JT : > > How this would affect memory performance on a workstation or server with much > more running concurrently, is something I can't really speak to, but I would > guess there's a point where increasing it could cause issues depending on > total memory available and how many processes are getting memory reservations > from the kernel. > At first glance it should be relatively easy to get at least a simple > baseline check on a busy workstation/server that isn't massively loaded with > RAM. A system that starts to run into memory pressure during heavy use > should reveal if this change causes problems under the same workload. Before introducing this change, we need to check and make sure that this change will not affect a server operation under any circumstances. And we need to look specifically at the impact on servers in virtualized environments, where memory is usually greatly reduced for cost reasons. I am currently strongly against introducing this change for Server Edition. At the moment I don't see any benefit for a server operation through this proposal. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
Interesting that this came up. I was just talking to someone else about this the other day. From what I understand, that sysctl affects the max number of memory map areas a process can have, i.e. contiguous reserved memory. For a game that's great because it can pack more into memory and decrease disk IO. My guess is that this is really not an issue for the Steam Deck because realistically it will only be doing a few things at once... Basic system, Steam Client, and the Game running. How this would affect memory performance on a workstation or server with much more running concurrently, is something I can't really speak to, but I would guess there's a point where increasing it could cause issues depending on total memory available and how many processes are getting memory reservations from the kernel. At first glance it should be relatively easy to get at least a simple baseline check on a busy workstation/server that isn't massively loaded with RAM. A system that starts to run into memory pressure during heavy use should reveal if this change causes problems under the same workload. On Mon, Apr 24, 2023 at 1:13 PM Kevin Fenzi wrote: > A few questions: > > * Could we perhaps try and get upstream to adjust this higher? > > * Is there any description/docs on what happens when this value is too > low? do games error in a particular way? > > * Is there any adverse impact increasing this? More memory used? > > Thanks for putting this together. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
A few questions: * Could we perhaps try and get upstream to adjust this higher? * Is there any description/docs on what happens when this value is too low? do games error in a particular way? * Is there any adverse impact increasing this? More memory used? Thanks for putting this together. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This change aims at increasing the default value of the `vm.max_map_count` sysctl == Owner == * Name: [[User:aleasto| Alessandro Astone]] * Email: ales.ast...@gmail.com == Detailed Description == Increase the vm.max_map_count sysctl default value. The goal is to improve compatibility with Windows games through wine or steam. Read on "Benefit to Fedora" for examples. Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up from `65530` of Fedora; it makes sense to follow their lead and set the same value. == Feedback == This was briefly discussed in #fedora-devel and received positively. Concerns over possible downsides were raised. I am not aware of any, but more input here is desired. == Benefit to Fedora == The following Windows games will work out of the box (through wine or steam): * DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/ * Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510 * Counter Strike 2 (Beta Windows build): https://www.youtube.com/watch?v=i02n_Ak98TA * Any other software that might be invoking a lot of mmaps == Scope == * Proposal owners: Add the new default to `/usr/lib/sysctl.d/` * Other developers: No work will be necessary unless the new default is found breaking some software * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Upgrading to the new Fedora release will seamlessly update the default. No manual intervention is necessary. == How To Test == Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642` Run any of the software listed above to verify that it now works. Or run any other software to verify the change causes no regression. == User Experience == More Windows games will work out-of-the-box (through wine or steam) == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: Final Freeze * Blocks release? No == Documentation == The default value is currently hard-coded in the kernel, at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203 . It cannot be changed through the kernel defconfig, instead it must be set through sysctl. == Release Notes == The default value of the vm.max_map_count sysctl is increased -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This change aims at increasing the default value of the `vm.max_map_count` sysctl == Owner == * Name: [[User:aleasto| Alessandro Astone]] * Email: ales.ast...@gmail.com == Detailed Description == Increase the vm.max_map_count sysctl default value. The goal is to improve compatibility with Windows games through wine or steam. Read on "Benefit to Fedora" for examples. Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up from `65530` of Fedora; it makes sense to follow their lead and set the same value. == Feedback == This was briefly discussed in #fedora-devel and received positively. Concerns over possible downsides were raised. I am not aware of any, but more input here is desired. == Benefit to Fedora == The following Windows games will work out of the box (through wine or steam): * DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/ * Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510 * Counter Strike 2 (Beta Windows build): https://www.youtube.com/watch?v=i02n_Ak98TA * Any other software that might be invoking a lot of mmaps == Scope == * Proposal owners: Add the new default to `/usr/lib/sysctl.d/` * Other developers: No work will be necessary unless the new default is found breaking some software * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Upgrading to the new Fedora release will seamlessly update the default. No manual intervention is necessary. == How To Test == Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642` Run any of the software listed above to verify that it now works. Or run any other software to verify the change causes no regression. == User Experience == More Windows games will work out-of-the-box (through wine or steam) == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: Final Freeze * Blocks release? No == Documentation == The default value is currently hard-coded in the kernel, at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203 . It cannot be changed through the kernel defconfig, instead it must be set through sysctl. == Release Notes == The default value of the vm.max_map_count sysctl is increased -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
