Announcement

Collapse
No announcement yet.

Fedora To Further Evaluate vm.max_map_count Tuning For Better Linux Gaming Experience

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Volta View Post

    Needs to try.



    Yes and it shutdowns easily, so there must be a way to kill those processes.
    I tried it in Boxes. Debian 12 and Ubuntu 23.04 behave exactly the same way. I think we can conclude with this short experiment that it's not a Fedora-only thing.

    Comment


    • #12
      Originally posted by jorgepl View Post

      I tried it in Boxes. Debian 12 and Ubuntu 23.04 behave exactly the same way. I think we can conclude with this short experiment that it's not a Fedora-only thing.
      I suspect setting soft/hard nproc limits in /etc/security/limits.conf should fix it but kernel defaults are not that safe:

      Code:
      [user@localhost ~]$ ulimit -u -S
      256952
      [user@localhost ~]$ ulimit -u -H
      256952

      Comment


      • #13
        If a million plus Steam Decks and Nobara have been running higher values, then I can think of at least two places the Fedora Engineering and Steering Committee can go to ask about how high the variable should be set, why it should be set there, and if there are negative consequences. Nobara is based on Fedora for cats' sake.

        Comment


        • #14
          Originally posted by Teggs View Post
          If a million plus Steam Decks and Nobara have been running higher values, then I can think of at least two places the Fedora Engineering and Steering Committee can go to ask about how high the variable should be set, why it should be set there, and if there are negative consequences. Nobara is based on Fedora for cats' sake.
          Both are gaming focused distributions. That targeted use case is well known and is driving the change proposal. However that doesn't help understand the impact on Fedora's broader audience including Fedora IoT, CoreOS, Desktop, containers etc. There have already been potential issues identified in the discussion in devel list.

          In my experiments, the kernel OOM handler does not terminate this mapping-creating process, but random desktop services first.
          If the identified problems like these are solvable and it is a good general default, this should be set by upstream kernel rather than at the distro level.

          Comment


          • #15
            Originally posted by archkde View Post
            This change does not reduce security at all. If you really want to clog your system by creating a huge number of mappings, you can do so from multiple processes right now (e.g. a fork bomb with each process allocating, dirtying and repeatedly loading several megabytes, maybe even in huge pages).
            I was according to Avis comment.

            And I don't know what you mean by "messed up kernel config", and "not allowing comments criticizing their choices" when I see plently of them.
            Just because you're seeing some negative comments it doesn't mean they're not censoring others, does it? Messed up config: voluntary preemption instead of low-latency desktop (but at least 1000Hz), a lot of debugging enabled, as for now terrible sched-utils governor.

            Combined with your misguided rant against inclusivity I guess you're just trolling because Fedora doesn't make exactly the decisions you'd like them to make.
            I'm very pro inclusiveness, believe me. I'd love to see 'inclusive' people in martial arts. I'd love to spar with them and show how exclusive I am. Same rules and fairness that would verify every single bit of this ideological movement. Instead we have 'inclusive' people working in IT and bringing everything they touch down. Why? Because they are there not because they have skills, but because they have something messed up.

            Comment


            • #16
              I would rather prefer a native port of Counter-Strike 2 instead of compatibility layers and the issues coming with them. Proton (WINE) is a necessity for games which makers are unwilling to support Linux. But in case of Counter-Strike I expect a smooth running native application.

              I’m a little wary if Valve is already investing too much resources in Proton (WINE) for companies which doesn’t help. Or doesn’t it need more until some tipping point is reached? WINE should help at the beginning but seeing how much effort from Valve this requires already I would focus on improving Linux as foundation itself?

              An “Award for best native Linux ports in 2023” within Steam could be a nice thing. Highlighting good work? Boosting sales?
              Last edited by hsci; 22 May 2023, 07:55 AM.

              Comment

              Working...
              X