Forum

Bonjour

@Vinceff a constaté que beaucoup de distribution linux a un paramètre vm_max_map_count trop bas pour certains jeux. En effet, il indique que cela peut entraîner le crash lors d'une partie pour des jeux gourmands (Hogwarts Legacy , Star Citizen). Par défaut , sur la plupart d'entre elle, la valeur est fixé à 65530. C'est notamment le cas pour mageia. Il a ouvert un bug chez Ubuntu pour demander à augmenter sa valeur à 2147483642. Ceux ci ont accepté cette modification et finalement choisi de le fixer à 1048576, valeur qui a été retenu chez fedora.

Si vous voulez changer cette valeur sous mageia, vous pouvez suivre la procédure ci dessous après s'être connecté root :



Appliquer le nouveau paramètre ( ou rebooter le système) :


Pour vérifier la bonne prise en compte du paramètre :

A voir s'il pourrait être intéressant de faire un bug pour disposer de cette amélioration.

Bonjour Vouf !
Merci pour le partage du côté de Mageia,

En effet, cette valeur de maps augmentent le niveau de risque d'avoir des crashs sur certains jeux, c'est à la sortie d'Hogwarts Legacy, que cette valeur m'est apparue réellement obligatoire, car simplement en jouant quelques minutes le jeu crashait avec un retour bureau.
Une fois fait ce que tu indiques ci dessus, plus aucun bug. Un quasi miracle

Pour les distributions, aujourd'hui Fedora, Opensuse, Solus, Pop OS, Garuda Linux ont déjà fait le changement.
Ubuntu a validé cette modification pour la prochaine LTS d'avril donc Ubuntu et ses dérivés + Mint + Zorin vont être automatiquement portés.

Nous avons également fait la démarche auprès de Arch, et un dev a répondu favorablement à cette demande, ils font un tour de table pour valider ou non ce changement, et cela devrait être acté courant de semaine prochaine.

Il est fort probable que nous fassions également une demande auprès de Debian fin de semaine prochaine.
Globalement, j'espère que tout le monde va y passer pour que tout les joueurs Linuxien en profite.

Si debian y passe également, nous ferons également une demande auprès du Kernel directement. Avec la liste de chaque distribution ayant déjà fait la bascule

Merci beaucoup d'avoir partagé la manip, elle se fait en quelques secondes et a un vrai impact sur le confort de jeu.
A bientôt

merci Vinceff

Pour info, la dernière version de Lutris devrait aussi arriver prochainement sur Mageia 9. Notre cher papoteur doit nous faire une dernière petite correction et je fais un dernier test et ce sera bon. Steam a aussi mis été à jour et devrait être plus rapide au démarrage pour ceux qui n'avaient pas lsof d'installé.

Bonjour Vinceff,
tu avances quels sont les avantages de ce nouveau paramètre.
Par contre, y aurait-il des inconvénients ?

Yuusha :

Pour info, la dernière version de Lutris devrait aussi arriver prochainement sur Mageia 9. Notre cher papoteur doit nous faire une dernière petite correction et je fais un dernier test et ce sera bon. Steam a aussi mis été à jour et devrait être plus rapide au démarrage pour ceux qui n'avaient pas lsof d'installé.

Excellente nouvelle ça ! Lutris 5.12 se fait un chouille vieillissant
Et les dernières mises à jour permettent d'avoir les update de vkd3d et dxvk en automatique à l'ouverture de lutris, c'est très appréciable, sans compter la mise à jour également de wine-ge.

J'ai aussi testé crossover sur mageia, et c'est pas loin de marcher super bien, il y a un leger soucis avec urpmi, car crossover fait un appel des dépendances dont il a besoin dans urpmi, mais il ne finit pas sa tâche . Il a la gentillesse de nous lister les dépendances qu'il souhaite installer, et en le faisant à la main et en testant à nouveau d'installer par exemple battle.net alors les dépendances sont considérées ok, et battle.net s'installe comme si on était sous windows, c'est vraiment appréciable.

Pour steam, je ne connais pas les impact, il a tendance à faire son auto maj non? je vois que mageia est en version 0.70 là où steam propose une version 0.79. Je n'ai aucune idée de l'écart (positif) que cela peut amener.

Papoteur :

Bonjour Vinceff,
tu avances quels sont les avantages de ce nouveau paramètre.
Par contre, y aurait-il des inconvénients ?

Bonjour Papoteur,

A ma connaissance cette valeur est surtout historique et correspond aux PC équipés de 8Gb de ram.
Qui a l'époque de cette décision étaient ultra rares, aujourd'hui ils sont la norme minimum (presque).
Lien Ram -> vm max map count

Aujourd'hui mon pc orienté gaming est équipé de 32gb et certains jeux vont parfois facilement au dessus de cette valeur de 8Gb de ram utilisée.
Ce qui engendre parfois une valeur de mmap utilisées supérieures de 65530 en décimal.

Fedora et ubuntu ont choisit la valeur de 1048576, ce qui correspond à une compatibilité avec les pc équipés jusqu'à 128gb de ram.
Cette valeur n'est pas aléatoire, elle correspond simplement à la valeur 100000000000000000000 (en binaire, rien de plus rien de moins )

Pour les risques, aujourd'hui il n'y en a pas de relevés à ma connaissance. Aujourd'hui dores et déjà pour certaines applications serveurs demandant beaucoup de ressources, cette valeur devait déjà être montée. C'est juste que le gaming est un nouveau cas d'application.

Donc pour ta question, je dirai non, ni remontée par fedora, ni ubuntu, ni arch ni ...

Édité par vinceff Le 04/04/2024 à 11h25

Steam fait en effet les mai auto. Mais au démarrage, il cherche lsof. Si le programme n'est pas trouvé, il tourne en boucle pendnant quelques secondes et affiche plusieurs fois que le programme n'est pas trouvé. En ajoutant lsof aux dépendances, le lancement de Steam, lorsqu'il n'y a pas de mise à jour disponible, est un peu plus rapide.

Yuusha :

Steam fait en effet les mai auto. Mais au démarrage, il cherche lsof. Si le programme n'est pas trouvé, il tourne en boucle pendnant quelques secondes et affiche plusieurs fois que le programme n'est pas trouvé. En ajoutant lsof aux dépendances, le lancement de Steam, lorsqu'il n'y a pas de mise à jour disponible, est un peu plus rapide.

Ah d'accord, je ne savais pas, en tout cas en effet, sur mageia, steam tourne super bien actuellement. Perso j'en suis très content en tout cas

vinceff :

A ma connaissance cette valeur est surtout historique et correspond aux PC équipés de 8Gb de ram.
Qui a l'époque de cette décision étaient ultra rares, aujourd'hui ils sont la norme minimum (presque).
Lien Ram -> vm max map count

Aujourd'hui mon pc orienté gaming est équipé de 32gb et certains jeux vont parfois facilement au dessus de cette valeur de 8Gb de ram utilisée.
Ce qui engendre parfois une valeur de mmap utilisées supérieures de 65530 en décimal.

Fedora et ubuntu ont choisit la valeur de 1048576, ce qui correspond à une compatibilité avec les pc équipés jusqu'à 128gb de ram.
Cette valeur n'est pas aléatoire, elle correspond simplement à la valeur 100000000000000000000 (en binaire, rien de plus rien de moins )

Pour les risques, aujourd'hui il n'y en a pas de relevés à ma connaissance. Aujourd'hui dores et déjà pour certaines applications serveurs demandant beaucoup de ressources, cette valeur devait déjà être montée. C'est juste que le gaming est un nouveau cas d'application.

J'ai ouvert une requête : https://bugs.mageia.org/show_bug.cgi?id=33079

Merci beaucoup Papoteur, je me suis permis d'ajouter le fait qu'ubuntu, fedora et arch avaient déjà fait le changement.

vinceff :

Merci beaucoup Papoteur, je me suis permis d'ajouter le fait qu'ubuntu, fedora et arch avaient déjà fait le changement.

C'est une bonne idée.
La question est maintenant de savoir de quelle manière cela est fait.
J'ai trouvé une indication que Fedora l'a fait dans le paquet systemd, mais je ne trouve pas ce paquet dans les sources :(

Papoteur :

C'est une bonne idée.
La question est maintenant de savoir de quelle manière cela est fait.
J'ai trouvé une indication que Fedora l'a fait dans le paquet systemd, mais je ne trouve pas ce paquet dans les sources :(

Apparemment ubuntu a choisit de modifier le paquet procps, je ne sais pas si ça peut aider.