Bar Le Linux BAR - Discussion de tout et de rien

[windu.2b]

À la fin de la semaine ?

Oki, on se fixe le WE prochain comme date

[windu.2b]

KDE 4.1 n'est pas encore officiellement sorti, mais déjà le premier mockup de ce à quoi on devrait au final arriver avec KDE 4.2 vient de sortir

Ca donne envie

[tuXXX]

Pour les Parisiens, y'a un first jeudi le 5 juin, http://paris.firstjeudi.org/first.php3 . Perso je pense que je vais y aller, si y'a des gens intéressés qu'ils fassent signe

[olasd]

Pour les Parisiens, y'a un first jeudi le 5 juin, http://paris.firstjeudi.org/first.php3 . Perso je pense que je vais y aller, si y'a des gens intéressés qu'ils fassent signe

Je m'suis inscrit, donc normalement je devrais venir

À jeudi !

[theocrite]

Je vais voir si ça ne me fait pas arriver trop tard.

[tuXXX]

Je m'suis inscrit, donc normalement je devrais venir

À jeudi !

Cool :8

[16ar]

Je viens de m'y inscrire

Je devrais passer suivant ma forme :)

[theocrite]

Finalement, ça va faire trop juste, j'ai des copies à corriger et un pc à tuner, le tout pour vendredi/samedi donc pas le temps de passer ce soir.

[neologix]

Salut à tous (ça faisait un moment...).

Dites, j'ai une question qui me turlupine.

Aujourd'hui je me suis "accroché" au boulot avec un collègue au sujet des impacts de la préemption.

Je pense que la préemption facilite les deadlocks, par exemple il y a plus de risques de deadlocks avec CONFIG_PREEMPT qu'avec CONFIG_PREEMPT_VOLUNTARY ou CONFIG_PREEMPT_NONE, tout simplement parce qu'il y a plus de sections critiques, et donc de problèmes de synchronisation. En plus, mon expérience personnelle me conforte dans cette idée : j'ai porté un ensemble de modules de 2.4 vers 2.6, et ça a révélé pas mals de problèmes de synchro (deadlocks, pointeurs foireux...)

Enfin, j'ai vu que les patches RT d'Ingo Molnar ont aussi permis de découvrir des problèmes similaires.

Des avis?

[lorinc]

Finalement, ça va faire trop juste, j'ai des copies à corriger et un pc à tuner, le tout pour vendredi/samedi donc pas le temps de passer ce soir.

des copies à corriger ???

[lorinc]

Salut à tous (ça faisait un moment...).

Dites, j'ai une question qui me turlupine.

Aujourd'hui je me suis "accroché" au boulot avec un collègue au sujet des impacts de la préemption.

Je pense que la préemption facilite les deadlocks, par exemple il y a plus de risques de deadlocks avec CONFIG_PREEMPT qu'avec CONFIG_PREEMPT_VOLUNTARY ou CONFIG_PREEMPT_NONE, tout simplement parce qu'il y a plus de sections critiques, et donc de problèmes de synchronisation. En plus, mon expérience personnelle me conforte dans cette idée : j'ai porté un ensemble de modules de 2.4 vers 2.6, et ça a révélé pas mals de problèmes de synchro (deadlocks, pointeurs foireux...)

Enfin, j'ai vu que les patches RT d'Ingo Molnar ont aussi permis de découvrir des problèmes similaires.

Des avis?

Hum. oui et non. J'aurais tendance à dire que je ne vois pas en quoi avoir une préemption plus souple augmente le nombre de section critiques. Les sections critiques le sont par essence (un variable partagée, un problème de réentrance, ...), et ceci indépendamment de quand précisément l'ordonnanceur décide de tourner. En fait, la majeure partie du temps utilisé l'est en espace utilisateur, ce qui rend totalement imprédictible le moment où ce situera le prochain ordonancement (dans le sens que l'on ne sait pas si cela arrive durant un code en mode noyau et si oui lequel).

L'INpact sur les deadlocks il vient surtout du nombre de sections critiques et du SMP. Après, j'aurais tendance à dire, peu importe le schéma de préemption.

mais je suis ouvert à d'autres explications

[eYo]

Juste une petite question

J'ai un processeur AMD64, j'ai toujours pris le CD pour cette architecture, mais je me rends compte qu'il y a "souvent" des soucis de compatibilités etc...

N'ai-je pas meilleur temps de faire une intsall i386 ? Y-a-t'il une perte importante de perf ?

[16ar]

Tu perdras des perfs sur des specificité qui ont été rajouté sur les x86 apres les 386. Donc ct surtout des améliorations multimedia.

Du coup, tu gagneras surtout sur de l'encoding et des choses du genre. Mais un gzip fonctionnera aussi vite quasiment. Voire il fonctionnera mieux sous i386 car au final il a moins de ram a gérer (suivant comment est compilé ton kernel amd64)

Mais bon, ca ne va pas loin. Donc pour une utilisation de tous les jours, un i386 est bien :)

[theocrite]

Finalement, ça va faire trop juste, j'ai des copies à corriger et un pc à tuner, le tout pour vendredi/samedi donc pas le temps de passer ce soir.

des copies à corriger ???

Vi je te raconterais le prochain first jeudi qu'on se fait si tu veux

[neologix]

En fait, la majeure partie du temps utilisé l'est en espace utilisateur, ce qui rend totalement imprédictible le moment où ce situera le prochain ordonancement (dans le sens que l'on ne sait pas si cela arrive durant un code en mode noyau et si oui lequel).

Justement, "on ne sait jamais". Sans préemption, tu sais que ton flot d'exécution ne sera pas interrompu (ou par une iterruption hard, mais on s'en fout ici), donc pas de problème. Tu parcours ta liste chainée, fais un kmalloc(GFP_KERNEL), manipule des données locales à un processeur, c'est pas grave. Mais dès que tu as de la préemption, et bien tu es obligé d'avoir recours à des {spin,read,write}_lock, à faire des kmalloc(GFP_ATOMIC), et de façon générale à introduire des méchanismes de synchronisation, et donc augmenter le risque de deadlock. En très schématique, preemption=>synchronisation=>deadlocks. En gros, ça augmente le parallèlisme de la machine. Maintenant, c'est vrai que normalement, du code SMP-safe est preemption-safe, mais il y a quelques exceptions :

Starting with the 2.5 development kernel (and 2.4 with an available patch), the Linux kernel is fully preemptible. This feature allows processes to be preempted by higher-priority processes, even if the current process is running in the kernel. A preemptible kernel creates many of the synchronization issues of SMP. Thankfully, kernel preemption is synchronized by SMP locks, so most issues are solved automatically by writing SMP-safe code. A few new locking issues, however, are introduced. For example, a lock may not protect per-CPU data because it is implicitly locked (it is safe because it is unique to each CPU) but is needed with kernel preemption.

For these situations, preempt_disable() and the corresponding preempt_enable() have been introduced. These methods are nestable such that for each n preempt_disable() calls, preemption will not be re-enabled until the nth preempt_enable() call. See the “Function Reference” Sidebar for a complete list of preemption-related controls.

Tiré de http://www.linuxjournal.com/article/5833

Aussi, il me semble que c'est pour cette raison qu'on ne peut pas faire de calculs en virgule flottante dans le noyau : si tu es préempté, comme le noyau ne sauve pas le registre FPU (en mode noyau :-), c'est le drame (en même temps, on peut très bien s'en passer ).

En fait, c'est surtout lorsque j'ai porté des modules du 2.4 (non-préemptif) au 2.6 que j'ai compris ma douleur (et non, je ne suis pas un hacker, loin de là ;-).

[Stargate 89]

Connaissais - vous des Linux simple comme la Xandros modifié du EeePc (que je possède) ?

J'ai vu Linpus mais je peu plus la télécharger (le serveur est down)

Ya aussi Midinux que j'aime bien : http://www.redflag-linux.com/chanpin/midinux/index.htm

Et j'ai trouvé Peeper Linux que je télécharge en ce moment : http://www.pepper.com/software/index.html

Sinon j'attendrais Ubuntu Mobile que j'installerais sur mon EeePc et mon 2ème Pc Portable (Pentium M Dothan 1,6 Ghz, 512 Mo Ram)

[nonas]

Vous n'auriez pas des astuces pour faire en sorte que quand un DD se vautre il n'emmène pas tout le système avec lui ?

Je m'explique : j'ai un DD qui rend l'âme (celui de mon /home), j'arrive encore à le monter et à lire quelques trucs mais au bout d'un moment il plante (j'ai pas réussi à savoir si c'est au volume lu ou si certains endroits sont vraiment morts) et la machine freeze, obliger de la rebooter au bouton (les MagicSysKeys ne fonctionnent pas non plus).

Des idées ? (parce que bon il me reste encore quelques gigas à lire et rebooter tout le temps (genre tous les 40 Mo) c'est long (et walou les gros fichiers...)

PS: c'est de l'ext3.

[theocrite]

Si tu utilises un dd_rescue en non monté, ça ne devrait pas poser de problèmes.

[Arafel]

+1 théo et ce que je ferais aussi, c'est déporter le /home... pour 2 raisons :

1) si le disque claque, tu ne perdras pas ton /home

2) le system va quand même chercher des fichiers de configuration dans /home donc normal que ça finisse par freezer si le disque lache...

par contre, tu peux toujours te servir du dit disque si tu le montes dans un sous répertoire du /home (exemples : /home/sauvegarde ou /home/nonas/sauvegarde etc...)

[nonas]

En fait j'ai déjà réussi à récupérer plein de petits trucs (notamment les fichiers de conf), que j'ai mis sur un autre DD qui sert de /home maintenant, l'autre ne fonctionne qu'en read-only depuis que je me suis rendu compte qu'il était malade. (d'ailleurs les SMART test long sur un raptor ça fait peur niveau bruit )

Enfin bon là, il commence à même plus vouloir se lancer ^_^" :pleure:

Merci pour dd_rescue, je vais regarder ça de près (si le disque veut bien, sinon j'aurais fait 20 Go de ménage en 1 journée \o/)

edit : en fait ça fonctionne pas, le disque s'arrête au bout de quelques secondes et la machine freeze peut après :(

Je teste les outils constructeurs et ensuite ça sera échange sous garantie (merci la garantie 5 ans !)

edit : le mystère grandit ! N'arrivant plus à booter rien du tout, le disque malade faisant tout planter, je me décide à ouvrir la boiboite pour le débrancher.

Mince, j'ai pas noté son numéro de série... Alors c'est celui du haut ou celui du bas ? Je débranche celui du haut, je tente de booter sur un livecd (sysrescuecd ) Résusltat, c'est le disque sain que j'ai débranché et ... le disque malade fonctionne de nouveau parfaitement...

Bref je fais un photorec dessus et on verra ensuite...

PS: génial les outils constructeurs qui marchent pas : Starting Caldera DR-DOS ... Écran noir

Peut-être que c'est parce que mes disques sont sur le contrôleur Promise et pas sur l'ICH ?!

[mezcalbert]

Après 2 ans d'utilisation d'Ubuntu (et 6 mois sur Mandriva 2005), j'aimerais tout doucement évoluer vers une distribution plus stable qu'Ubuntu (Hardy n'étant pas du niveau de Gutsy) sans trop perdre le côté "bleeding edge".

J'hésitais entre:

- Fedora 9, avec une certaine appréhension vis-à-vis des RPMs;

- Debian Lenny, avec une certaine appréhension vis-à-vis du niveau requis.

Et, dans une moindre mesure:

- Open Solaris (Indiana), qui a l'air plutôt attrayante et qui évolue bien.

Je précise encore que je maîtrise tout doucement les fondations des systèmes GNU/Linux, et donc que mettre les mains dans le cambouis n'est pas un obstacle, si ça ne se résume pas à ça.

Plutôt que de parcourir les forums et les guides, j'aurais aimé avoir l'avis d'utilisateurs éclairés. Que me conseilleriez-vous?

[theocrite]

Si tu es déjà habitué à Ubuntu, lenny ne devrait pas trop de dépayser. Après c'est une affaire d'appréciation personnelle.

[tuXXX]

Après 2 ans d'utilisation d'Ubuntu (et 6 mois sur Mandriva 2005), j'aimerais tout doucement évoluer vers une distribution plus stable qu'Ubuntu (Hardy n'étant pas du niveau de Gutsy) sans trop perdre le côté "bleeding edge".

J'hésitais entre:

- Fedora 9, avec une certaine appréhension vis-à-vis des RPMs;

- Debian Lenny, avec une certaine appréhension vis-à-vis du niveau requis.

Et, dans une moindre mesure:

- Open Solaris (Indiana), qui a l'air plutôt attrayante et qui évolue bien.

Je précise encore que je maîtrise tout doucement les fondations des systèmes GNU/Linux, et donc que mettre les mains dans le cambouis n'est pas un obstacle, si ça ne se résume pas à ça.

Plutôt que de parcourir les forums et les guides, j'aurais aimé avoir l'avis d'utilisateurs éclairés. Que me conseilleriez-vous?

Je dirais que dans l'ordre de stabilité c'est plutôt :

Debian : (trop?) stable

Ubuntu : compromis

Fedora : (trop?) bleeding-edge

[mezcalbert]

Debian : (trop?) stable

Y compris la testing (Lenny)?

[Arschney]

Debian : (trop?) stable

Y compris la testing (Lenny)?

Ben, testing en période de freeze, ça évolue pas des masses...

Et le rattrapage derrière peut être un peu... violent... (bis)