Je viens de découvrir sur ce lien : https://blogs.gnome.org/shell-dev/ (chercher "Real-Time Scheduler") que GNOME avait une fonctionnalité expérimentale permettant d'être schedulé en temps réel.
C'est une fonction que j'ai toujours souhaitée, ne sachant pas comment la réaliser. J'ai souvent joué avec les paramètres nice et ionice sans succès, j'ai toujours eu des freeze dans GNOME alors que d'autres interfaces basées sur Linux semblent pouvoir gérer ça plus proprement (Android…)
Et voilà, c'est là.
Je rêve d'autre chose aussi, aucun accès IO dans le fil d'exécution principal du rendu du shell, mais c'est peut être déjà le cas (et de plus en plus, avec wayland, les imperfections deviennent de plus en plus criantes). En effet, j'ai longtemps fait de la résistance et me suis traînée un disque dur rotatif en lieu et places des SSD plus modernes (mais plus onéreux également). En tant que développeur, je me dis que si je ne compte pas sur l'optimisation d'un SSD, je ferais forcément du code moins pourri en terme de performances. mais a mon avis ça passe par des langages plus proches de la machines tout en restant modernes, comme Nim que je viens de découvrir pour remplacer les monstres comme Javascript.
En tout cas l'astuce pour le scheduler temps réel dans GNOME est simple :
gsettings set org.gnome.mutter experimental-features "['rt-scheduler']"
getcap /usr/bin/gnome-shell
setcap CAP_SYS_NICE=+ep /usr/bin/gnome-shell
# Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . Évalué à 5.
Je ne pense pas que ça apporte du bien : ça ne fait que repousser le problème. Soit tu n'avais pas réellement besoin de cette I/O, dans ce cas il faut corriger le code, soit tu en avais vraiment besoin et tu vas inventer la roulette à la MacOS ou équivalent. Le truc c'est que tu ne géreras jamais tous les cas possibles où t'as besoin d'I/O, car t'auras toujours des I/O abstraites derrières 3 couches à travers 10 appels de fonction que tu ne connais pas. Donc ça bloquera, buguera, ou autre.
De toutes façons, les systèmes qui veulent ainsi cacher les latences sont « mous » dans le sens où en voulant cacher le feedback, on perd tout lien avec le besoin réel de resource (ici en I/O) derrière : ya le même problème sur le Web avec tout le JS qui attend des resources réseau sur une connexion lente, et c'est tout moisi quand tout est (presque) géré par le JS lui-même avec masse d'artifice pour te faire attendre. C'est même un principe « physique » si on peut dire : c'est la base des circuits en boucle fermés, dans lesquels tu rajouterais de la capacité (pour les électroniciens, mettre de la capa ça « résout » magiquement tout les problèmes ; mais en fait ça en ajoute plein d'autres). C'est pareil en réseau avec l'ajout de buffer, en algorithmique en ajoutant des caches (de la mémoire), etc.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par Ruminant . Évalué à 10. Dernière modification le 29 avril 2020 à 23:37.
On peut quand même essayer de limiter la casse : par exemple, nautilus ne devrait pas (à mon avis, hein) complètement freezer dès qu’il essaye d’accéder à un partage réseau en berne.
On devrait quand même être capable de le fermer, ou simplement de naviguer dans d’autres dossiers etc.
Il est inutile et effectivement illusoire de vouloir rendre tout "parfait", on peut au moins éviter de galérer comme des ânes et rendre les choses plus fluides. Vu que les utilisateurs sont humains, on peut se permettre quelques dizaines de millisecondes de freeze par-ci par-là, en quelque sorte :)
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . Évalué à 0.
Alors pour le partage réseau, déjà, est-ce que c'est un partage abstrait par le VFS ou alors une API spécifique à Nautilus (ou une lib qu'il utilise spécifiquement) qui lui permet de savoir que c'est un partage réseau ? Dans le premier cas, ça obligerait à complexifier le cas pour tous les accès même locaux, et ça causerait sûrement plein de problèmes de consommation et complexification supplémentaire pour uniquement ce problème particulier. Dans le second, il y a effectivement peut-être des choses à faire, mais il faut essayer de comprendre le besoin : le réseau ajoute intrinsèquement des latences, alors combien de temps il faut attendre avant de dire qu'il est « en carafe » ? Est-ce une erreur transitoire ou permanante (et on démonde le partage) ?
Certes, pouvoir fermer la fenêtre devrait être une option accessible, mais si je peux me permettre le tirage de cheveu, la question de l'informatique a toujours été de cacher les modalités, et là donc la modalité du « je suis dans un dossier du partage réseau », que tu la recrées en fermant la fenêtre et en allant en rouvrir une autre pour aller au même endroit et te reprendre la même erreur… quel intérêt ? « Attendre que ça revienne » peut être une solution également valable ! Ça me fait penser à ceux qui rechargent leurs pages pour régler leur problèmes : TCP a été inventé (dans les années 70 !) pour réessayer à votre place, sans que vous ayez besoin de le faire vous-même ! (vous n'êtes pas des machines ! Bien que les devs prennent souvent leurs utilisateurs pour des automates débiles)
Surtout que si on essaye de remonter à l'origine de ce problème, ça n'est pas le blocage de ton navigateur de fichier (qui n'est qu'un symptôme), mais de mon expérience personnelle c'est très souvent dû à des sessions effacées inutilement, que ça soit niveau firewall, NAT, ou système d'authentification : encore des modalités qui n'ont parfois aucune raison d'être (le NAT et autre état intermédiaire là pour contourner une difficulté technique plus ou moins involontairement créée par l'homme) et qui doivent être résolues par l'utilisateur, en rechargeant, se reloggant, en fermant/rouvrant, en redémarrant, etc ! C'est débile. Corrigeons d'abord ces conneries afin d'avoir un réseau plus fiable, après on aura moins de problème avec les GUI.
Tu vas me dire « oui mais en attendant on pourrait avoir ces workaround dans la GUI », mais si ça fait 20 ans qu'il y a les même problèmes (car ça fait vingt ans que la complexification des réseaux fout la merde) et qu'ils n'ont toujours pas été résolus dans la GUI, c'est peut-être qu'il faut arrêter de chercher des workaround et corriger les problèmes dans le réseau.
Désolé de la digression, mais t'es tombé pile sur un truc qui m'énerve.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par barmic 🦦 . Évalué à 10.
Pourquoi poster un commentaire énervé à 1h du mat' ? (si tu es dans la tz de Paris)
Dans le premier cas ça permet aussi de gérer les disques qui ont des erreurs (physique, mal branchés, autre). C'est une I/O ça peut planter tenter de ne gérer que les cas que tu imagine c'est généralement en oublier un énorme paquet. Et en terme de complexité ça n'est pas forcément si incroyable que ça. Du moins ça peut l'être si ton design a était prévu pour.
Si tu freeze ton application, flinguer ton application est la seule option qui reste à ton utilisateur. Si non tu pourrais lui expliquer ce que tu es entrain de faire, ce qui plante, lui donner des billes pour savoir si c'est transitoire ou non…
Donc au lieu de faire en sorte que les UI restent réactives donnent des info à leur utilisateurs, il faut qu'ils investiguent eux-même d'où vient ton freeze, qu'ils regardent toutes les I/O de leur machine et potentiellement de leur réseau et corrigent le problème. Tant pis si tu es sur un wifi publique ou si ta connexion est mauvaise (réseau mobile hors jolies 4 ou 5G ou alors ligne physique mais en défaut sur le moment) ?
Les développeurs d'intellij sont entrain de bosser là dessus comme ils l'ont dis au début de l'année (IntelliJ Platform Roadmap for 2020).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par benoar . Évalué à 2.
Parce que c'est énervé mais pas méchant ; j'avoue réfléchir à deux fois si c'est méchant, mais si c'est juste du HS je poste.
Il faut gérer tous les cas d'erreur, bien sûr, mais là on parle de latence dans la réponse ; et sur la complexité, j'ai l'impression que vous avez tous des ressentis sur la théorie que devrait être cette gestion, mais vous oubliez que « Worse is better ». En fait, il y a incompréhension sur l'objectif : bien sûr que j'aimerais une GUI qui soit tip-top et ne laggue pas, mais posez-vous la question de pourquoi c'est toujours difficile de résoudre un problème qui a 20 ou 30 ans et n'en finit pas ?
Je sais pas qui sont tes utilisateurs… si c'est transitoire, il faut… attendre, il n'y a rien d'autre à faire (comment pourrais-tu indiquer « ça va arriver dans 1 minute » ? Tu n'es pas devin !), et si c'est permanent, c'est que le feedback est bloqué pour une raison à la con (perte d'état intermédiaire que j'expliquais plus haut), et il faut corriger ça, parce qu'il n'existe pas de super heuristique sur « j'ai pas de feedback depuis X temps donc il faut abandonner » (pour info, dans TCP c'est 30 jours environ et c'est très bien comme ça).
Mais si ton appli est capable d'avoir des infos, pourquoi elle freeze ? Quand l'appli freeze, c'est qu'elle est en attente sans en savoir plus. Que veux-tu dire à l'utilisateur qui permettra à lui de changer la situation, quand tu es en attente d'une machine à l'autre bout du réseau ? Mon point de vue c'est de vous demander de pousser la réflexion plus loin que la première étape qui est le feedback visuel, en se demandant ce que ça va changer à l'issue de la tâche qu'est en train d'effectuer l'utilisateur.
Si ta connexion est lente, c'est quoi ton issue ? Attendre ou te barrer. J'ai jamais été contre « se barrer » dans mes commentaires plus haut, si c'est pour définitivement abandonner. Ce qui est un constat d'échec. Et dans l'autre cas, il faut… attendre.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par barmic 🦦 . Évalué à 5.
Ok en fait on ne s'est pas compris.
Le freeze c'est le fait qu'une interface graphique ne réponde plus.
Tu peux très bien organiser ton code pour que le fil d'exécution qui gère l'interface ne fasse que la gestion de l'UI et interactions avec le gros du logiciel. C'est l'architecture qui était généralisée sur BeOS (d'où le commentaire plus bas). C'est ça qui est reproché.
Déjà avoir systématiquement ce retour ce serait énorme. C'est ce feedback qui permet à l'utilisateur de mieux comprendre ce qui se passe et pourquoi des choses prennent du temps. Et ça lui permet de faire des choix plus éclairé que ce que son imagination va donner.
Ensuite la logique voudrait que tu ne puisse pas modifier un traitement en cours, uniquement l'annuler. Mais c'est un pas bien plus compliqué à mettre en place.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par groumly . Évalué à 10. Dernière modification le 30 avril 2020 à 09:27.
En somme, ce que tu dit c’est que c’est pas un problème de faire de l’io bloquante sur le main thread parce que tu peux bien attendre 1 minute le temps que ton disque en train de lâcher laisse tomber?
Et qu’au lieu de faire gaffe à garder nos applis réactive, on ferais mieux de faire en sorte qu’un process (effet de bord sur le monde physique initié depuis le monde virtuel, en l’occurrence) qui part définition peut partir en couille ne parte jamais en couille?
C’est comme si je disais “construire des amortisseurs c’est trop compliqué, on ferait mieux de s’assurer qu’aucune route n’ait de nid de poules, et que personne n’ait besoin de faire un freinage d’urgence”.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par gnumdk (site web personnel) . Évalué à 4.
C'est déjà le cas, ca ne freeze pas si tu utilises Gio… Avec un montage noyau, là par contre, nautilus il peut rien faire.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par Ruminant . Évalué à 1.
Je prenais ce logiciel comme j’aurais pu prendre un autre, c’était pour illustrer :)
Mais effectivement je n’ai pas eu de freeze depuis un moment avec lui.
[^] # Re: Aucun I/O dans le fil d'exécution principal est irréaliste
Posté par cedric . Évalué à 4.
Sauf qu'on parle ici d'interface graphique. Une fois que tu as chargé le thème et les font, tu n'as plus d'IO nécessaire pour le rendu graphique et même pour l'interactivité. Après il y a une balance avec ton cache et tu peux te retrouver à ne pas avoir toutes ces ressources en mémoire, mais globalement la partie interface ne devrait dépendre du disque que pour la première frame.
L'intérêt du coup d'avoir un scheduler rt, c'est probablement pour les thread en charge du rendu qui ont une deadline fixe de 14ms. Généralement le Shell tourne avec une priorité supérieur au reste des applications et ca suffit pour atteindre cette deadline. Je suis du coup pas super convaincu. De plus la majorité de la deadline va être dans la dépendance avec le gpu qui lui ne va probablement pas scheduler les requêtes en fonction du process qui lui envoie les commande. Après c'est probablement le changement le plus simple à coder pour gratter un peu de performance.
# Avantages/inconvénients
Posté par antistress (site web personnel) . Évalué à 4.
Salut, merci pour l'info !
Je suis aussi confronté à des freezes, ne serait-ce qu'en copiant des fichiers entre deux disques dans Nautilus…
Peux tu préciser quels sont les avantages/inconvénients du rt-scheduler ou n'y a t-il que des avantages ?
[^] # Re: Avantages/inconvénients
Posté par antistress (site web personnel) . Évalué à 4.
J'ai ma réponse : c'est tout bénéf
https://blog.martin-graesslin.com/blog/2017/09/kwinwayland-goes-real-time/
# Question opportuniste
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 7.
Les accès I/O, on est d'accord, c'est quand le disque dur fait crac-crac-crac ?
Je me permets de poser la question car depuis ma fresh install d'Arch il y a quelques mois, mon disque dur continue de faire crac-crac-crac bien après que le boot soit terminé et que mon GNOME soit chargé, ce qui met un coup de mou au démarrage de n'importe quelle appli pendant au moins cinq minutes. (mon Windows 10 sur la même machine met un peu plus de temps à booter mais ne broute pas ensuite, lui)
À en croire le moniteur système (si j'arrive à le déchiffrer correctement), le coupable serait Tracker. Mais pourquoi ruminerait-il à chaque boot alors que je n'ai pas de nouveaux fichiers à scanner depuis ma session précédente ? C'est typiquement le genre de question à laquelle je n'arrive pas à trouver de réponse moi-même sur Google. Est-ce un comportement normal, un bug connu ? Si un jour je remplace mon disque dur par un SSD, ne va t'il pas s'user prématurément à cause de ce genre de truc ?
[^] # Re: Question opportuniste
Posté par gUI (Mastodon) . Évalué à 6.
Toi tu le sais, mais lui, comment le sait-il ? Bon, je ne sais pas si c'est aussi bourrin que ça, mais faut bien qu'il découvre qu'il ne s'est rien passé.
Sinon tu te sers de l'indexation des fichiers ? Si comme moi tu sais à peu près où sont tes fichiers, que de temps en temps du lances un recherche mais que t'as pas besoin que le résultat soit instantané, voire que tu ne recherches jamais sur le contenu des fichiers, mais simplement sur les noms ou les dates (les métadonnées quoi), tu peux carrément le désactiver.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Question opportuniste
Posté par antistress (site web personnel) . Évalué à 4.
Avant de le désactiver, on peut aussi le réinitialiser au cas où il aurait un pb :
tracker reset --soft
ou tracker reset --hard
aujourd'hui tracker est indispensable pour certaines applis (très limitées à mon avis) genre music photos etc je crois
Par contre sachez que ce n'est pas lui qui gère la liste des fichiers récemment utilisés ;)
[^] # Re: Question opportuniste
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Il est indispensable à Musique et Jeux que j'utilise régulièrement en effet. Donc, pas question de le désactiver complètement. J'essaierai ta suggestion dans le week-end.
(quant à la question du bien-fondé de la politique de GNOME d'utiliser Tracker dans ses applis, j'attendrais la sortie de Tracker 3.0 et/ou que Photos ait résolu sa crise existentielle avant de me prononcer dessus.)
[^] # Re: Question opportuniste
Posté par antistress (site web personnel) . Évalué à 3.
On peut être contre par principe et j'avoue que je ne suis pas emballé moi-même
par contre une fois l'indexation réalisée force est de reconnaître qu'il n'y a pas de consommation particulière associée en pratique pour ma part
[^] # Re: Question opportuniste
Posté par nonas . Évalué à 5.
Sache que les SSD récents et de qualité sont capables d'endurance très impressionnantes qui sont parfois exprimées en Drive Writes Per Day. Autrement dit, un SSD à 1 DWPD devrait pouvoir être réécrit entièrement chaque jour pendant toute sa durée de garantie.
Autant je comprends bien qu'il y a 10 ans on pouvait avoir des doutes, autant aujourd'hui je ne comprends pas qu'on trouve encore des excuses pour se passer d'un SSD pour son disque système (sauf considération écologique). Ça change vraiment la vie !
# Et sinon tu as quoi comme version
Posté par gnumdk (site web personnel) . Évalué à 3.
Parce que depuis la 3.36, j'ai jamais eu un seul lag sous Wayland…
[^] # Re: Et sinon tu as quoi comme version
Posté par Mildred (site web personnel) . Évalué à 2.
A vrai dire je n'utilise pas wayland, à cause d'un bug problématique: le clic-milieu sur une barre de titre dans une fenêtre avec les décorations coté appli ne rabaisse plus la fenêtre en dessous des autres. Et gnome-terminal a une décoration coté appli.
Par contre, même sans wayland, et avec un disque rotatif pour le coup, dans les moments de forte charge, j'avais souvent des ralentissements ou des freeze de quelques secondes (je fais exprès d'afficher la date avec les secondes pour savoir si c'est moi ou si c'est l'ordi et que c'est à moi d'attendre). J'avoue que sur les dernières versions (je suis toujours sur les dernières versions de GNOME grâce à une Fedora toujours à jour) j'ai vu moins de problèmes. Et avec un SSD plus la configuration realtime, je m'attends a ne plus rien voir.
# Une petite coquille sur le lien vers Nim
Posté par kreako . Évalué à 2.
Le lien du site vers le langage n'est pas le bon : https://nim-lang.org/
sed s/nil-lang/nim-lang/Je n'ai jamais utilisé sérieusement ce langage, donc ça restera un commentaire sur la forme et sans fond. :)
[^] # Re: Une petite coquille sur le lien vers Nim
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# BeOS faisait ça dans les années 90
Posté par dinomasque . Évalué à 7. Dernière modification le 30 avril 2020 à 15:26.
Du coup, je me demande pourquoi il y tant de retard dans les interfaces graphiques sous GNU / Linux …
BeOS le faisait il y a 20 ans !
[^] # Re: BeOS faisait ça dans les années 90
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 30 avril 2020 à 22:33.
Gnome va enfin avoir une horloge qui fonctionne normalement, capable d'afficher une vraie seconde tout le temps ? «Ceci est une révolution !»© (peut être, si ce scheduleur peut lui servir, ça serait bien la première chose à améliorer)
Poussez pas, je sors, c'est dredi avant l'heure
# Aucun accès IO dans le fil d'exécution principal du rendu du shell
Posté par Alex G. . Évalué à 3.
Ce serait vraiment pas du luxe !
Moi j'ai régulièrement des problème réseaux et Gnome shell qui freeze pendant plus d'une minute, voir cinq minutes, c'est rageant ! Tu as un problème et en plus tu ne peux rien faire… Pareil pour l'insertion d'un disque externe ou téléphone un peu mou, tout freeze !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.