Reprise du message précédent :
+1, depuis xfce 4.14, juste avant l'entrée en session de bureau, j'ai régulièrement (pas toujours) un affichage psychédélique pendant une petite seconde.
Carte graphique Radeon HD 7310, pilote libre.

J'ai aussi le coup du framebuffer/texture non initialisée qui contient des trucs random ou d'avant (genre des fois je lance un jeu, la première frame c'est une image de la dernière vidéo que j'ai regardée)
 
Ca le fait encore plus sur wayland d'ailleurs.
 
Rien de très inquiétant mais ça fait un peu tâche.

Enfin une proposition d'optimiser plus Arch comme a la belle epoque! Mais ca pourrait limiter la distribution a uniquement des processeurs recents, attention...
 
J'attend cette nouvelle depuis que Clear Linux déboite toute autre distribution niveau performance.

Tu peux donner le lien où tu as vu cette info ?
 
Ça m'inquiète car j'ai un vieux CPU (intel core 2 quad), il faut que archlinux continue à proposer une distribution pour tous les PC, comme les autres.

C'est sur la ML.

A la base Arch Linux c'etait uniquement 686+ contrairement au 386+ des autres distributions, la certains voudraient faire pareil avec AMD64, mais il y a aussi d'autres possibilités.

Et cela apporterait de réelles différences?

Ne plus fonctionner sur la machine d'Elbarto en serait une.

Le lien ici :
https://lists.archlinux.org/piperma [...] 29914.html

Mon CPU est 64 bit, dont compatible AMD64.

Les extensions utilisées :

Il manque l'AVX, le FMA, qui ont été introduits sur certains processeurs intel et amd à partir de 2011.

Peu de différence, voire pas du tout, car il faut que le programme soit conçu pour utiliser les extensions dernier cri type AVX, FMA, le développeur dans le code source doit spécifiquement y faire appel, et réfléchir pour que son algo utilise ces extensions, c'est pas évident :
https://www.hardware.fr/articles/81 [...] n-avx.html

Un CPU de 2009 comme le mien fonctionne encore très bien pour les usages du quotidien : surf internet, vidéo HD, retouche d'image, bureautique, il faut aller vers du calcul scientifique, deep-learning, du jeu 3D exigeant pour ressentir le besoin d'un CPU post 2010.

Mesa 20.0 est disponible dans Extra.

Non le développeur ne doit pas forcement y faire appel spécifiquement.
L'auto vectorization existe dans plusieurs compilos, et aussi derrière certaines libs (OpenMP..etc..).

J'y crois pas trop à la magie du compilateur qui augmente les performances d'un algo, sans que le développeur mette les mains dans le cambouis, mais pourquoi pas.

Ce n'est pas vraiment de la magie, c'est un peu le but du compilateur au final, sinon on en serait encore a l'asm.
 
Pareil pour l'existence de O2, O3, Os, etc, ce n'est pas juste de la décoration. Apres il y a aussi FDO/PGO qui donne bien, mais la ca devient plus lourd.
 

Je te conseille un peu de lecture sur l'état de l'art alors https://gcc.gnu.org/projects/tree-s [...] ation.html https://llvm.org/docs/Vectorizers.html

Plus rien depuis 9 ans.

 
FDO/PGO ne dépendent pas d'instructions spécifiques des CPUs modernes.

Je sais bien, je parlais des compilateurs en générals.

Depuis la dernière mise à jour du noyau linux  5.5.13 : avez-vous remarqué que le boot dure 5 secondes de plus ?

J'ai cette impression lorsque je selectionne archlinux dans le menu de grub, il y a alors un écran intermédiaire (juste avant le lancement de systemd) où je peux voir le message "load initial ramdisk", d'habitude cet écran est très rapide (à peine 2 secondes), mais depuis la mise à jour du noyau linux cet écran intermédiaire dure au moins deux fois plus longtemps (5 secondes).

Ça ne m'a pas frappé, et comme je fais exactement la même chose tous les matins à ce moment-là, je pense que je l'aurais remarqué…

C'est pas flagrant comme lenteur, et si je n'avais pas fixé l'écran je n'aurai pas remarqué .
Comme j'ai plusieurs noyaux j'en ai testé d'autres, cette étape "load initial ramdisk" est alors un chouilla plus rapide par rapport à celle concernant le récent noyau 5.5.13.

J'ai relancé la génération de l'image avec la commande "mkinitcpio -p linux" mais ça ne change rien, il doit y avoir des choses un peu plus lentes à charger et à s'initialiser dans l'image disque du noyau 5.5.13.

https://fr.wikipedia.org/wiki/Initrd

Les modules et hooks présents dans l'image :

Je précise que j'utilise un disque dur classique, et que mon PC n'est pas récent.

Oui mais justement, comme je suis en install chiffrée avec le /boot en clair, c'est à l'issue de cette phase de pré-boot que je rentre mon mot de passe, donc c'est pour ça que je pense que je l'aurais remarqué.
Après par contre, je laisse l'ordi démarrer tranquille en allant faire autre chose, parce que j'ai pas de mot de passe pour la session graphique.
Mais bon, peut-être que j'ai loupé ça malgré tout, ou bien c'est lié à une config particulière que tu as et que je n'ai pas
 
Comme hooks et modules dans /etc/mkinitcpio.conf, j'ai ça :

Et pareil, disque dur classique et pc pas récent.

Je viens de faire un petit test, pas vu de lenteur particulière ( disque dur WD de 1 To en 7200 tr/min )
 

 
 
Mon installation va approcher des 2 ans, et c'est sans doute déjà fait    
 

 
edit : merdum j'ai booté sur le noyau lts, faudra que je reteste avec le dernier noyau normal

c'est marrant mon avion de chasse met le même temps, mais il y a 16s de firmware (efi ?) et 2s de loader (grub) en plus. Pourquoi tu n'as pas ça toi ?
 

Nouvel essai avec le dernier noyau, ça boote aussi rapidement qu'avant, rien à signaler    
Installation classique sans EFI ( ma carte mère est compatible mais aucun intérêt de l'utiliser )
 

Pas du arch mais sur une config en U de la même génération :

 
Sur mon Lenovo T450s, installation chiffrée avec /boot en clair, à mon avis les 10s de kernel prennent en compte le temps que je passe à taper mon mot de passe

J'ai désactivé[ quelques trucs dans le bios et j'ai gagné un peu :

Je pourrais peut-être gagner un peu encore en enlevant le boot legacy et d'autre trucs que je n'ose pas trop tester, mais j'ai l'impression que le bios et long sur ce portable, le logo Dell reste un moment à l'écran...

Oui faut pas chercher à trop trafiquer le Bios, certains sont plus longs que d'autres et faut faire avec  

de toute façon, je laisse en veille la plus part du temps.

Moi aussi mais mon abruti de chat vient marcher sur le clavier la nuit et fait sortir le PC de veille  

Ne peux-tu pas le débrancher ou l'éteindre?
Perso je n'ai qu'un PC et il reste toujours allumé pour différentes mauvaises raison...

Désactive le réveil par le clavier.

Sinon, pour les temps de démarrage (sur mon portable avec HDD 5400 tr/min, pas sur le desktop) :

Peut-être que le démarrage a pris une seconde sur le chargement du noyau, mais je ne saurais pas dire quand ça s’est fait exactement. Il y a aussi l’invite LightDM qui semble prendre du temps à s’afficher (3 à 5 secondes, on va dire, au pif).

Vu que ça parle de temps de démarrage, j'ai le problème inverse depuis quelques temps, l'ordi est ultra long à s'arrêter.
Il reste en écran noir avec un "_" blanc clignotant pendant ~5 minutes avant de réellement s'arrêter.
 
Des idées de cause possible ou de comment diagnostiquer ça ?
 
Merci

A tout hasard, est-ce aussi long pour redemarrer?
 
Si non, c'est peut-etre un soucis matériel/bios, si oui il doit bien y avoir un log qui dit sur quoi ca travaille.

J'ai été regarder journalctl et en effet il y avait bien les infos dans les logs  
 

 
Plus qu'à trouver pourquoi ça timeout

de mon coté ça donne ça :

mon boot kernel est une seconde et demi plus lent par rapport au CPU de Trit, qui est à peu près de la même génération que le mien ( intel core 2, le mien est un intel core 2 quad Q9650 3 Ghz).

Ça vient peut-être du module "radeon" qui est incorporé dans l'image ramdisk du noyau, dans la version 5.5.13 du noyau il y a peut-être un bug qui ralentit son chargement lors du boot kernel ?

Ca timeout parce que ça en a eu marre d'attendre.
Ce que tu veux savoir, c'est pourquoi ça ne s'est pas fini rapidement.

Oui c'est ce que je voulais dire, plus qu'à trouver pourquoi pcmanfm, gmain et gdbus ne quittent pas normalement.

J'avais une intuition à propos d'une entrée fstab d'un disque externe qui fait freeze pcmanfm pendant quelques secondes quand on passe sur le dossier contenant le mountpoint, mais même en commentant les entrées fstab le problème reste le même.

En attendant, j'ai baissé le timeout de 90r à 10s comme palliatif, mais c'est un poil crade comme solution

C'est un peu gros, peut-etre devrais tu tenter 30s pour commencer.
 
Je crois que tu peux changer ce chiffre par service, mais comme tu ne sais pas trop ce qui met du temps ca ne t'aidera pas des masses.

Bof… Windows a pas défaut un timeout de 20 secondes, et il arrive parfois que le service « Hôte de tâches » (Task Host, le fameux svchost.exe) traîne un peu lors de l’arrêt. Il se fait tuer quand le délai est passé, et ça ne pose pas plus de problèmes que ça de les forcer à se quitter. Pourquoi ce serait le cas sur Linux (où j’ai aussi abaissé à 20 s la durée d’arrêt, car j’ai aussi eu des cas où ça mettait un temps fou pour que systemd close¹ la session utilisateur) ?
 
¹ Zut, le verbe « clore » est défectif et n’a pas de subjonctif imparfait… >__<

Salut,
 
Depuis le début du confinement, je télétravail depuis ma machine Arch (sous kde/plasma), avec ces différents logiciels :
- openfortivpn
- Krdc
- Oracle SQL Developer
- Eclipse STS
- Code OSS (version open source de VSCode de M$)
- Filezilla (accès FTP / SFTP)
- Chromium et Firefox
 
La plupart du temps, aucun problème, sauf que de temps en temps (une fois par jour max), j'ai un blocage quasi total de mon interface graphique, qui bouge à genre 0,01fps ...
 
Je suis oblige de faire un hard reboot à chaque fois et je ne trouve rien dans les logs qui pourrait m'aiguiller vers le / les responsable(s).
 
Des idées ?
 
Merci d'avance