Il ne gère pas l'authentification CRAM-MD5 ou CRAM-SHA1 avec l'IMAP (authentification type Challenge/Response qui permet de ne pas transmettre le mot de passe de manière plus ou moins directement lisible (non, base64 ne protège pas de la lecture)).
J'ai un peu peur, tu n'as pas compilé avec -lc_r comme option j'éspère ? Bien "-pthread" comme cela doit être fait (voir FAQs, mans et livres de sorcellerie). Les threads natifs comme tu les appellent sont ceux accessible à travers cette interface que sont les pthreads, donc j'ai du mal à suivre ton histoire de pthread /= threads natifs. Si tu me parles de GNU pth là je comprends un peu mieux. Lier directement un programme avec libc_r (c-à-d sans l'option "-pthread" pour le linker) est très gruik, et surtout risque fortement de déconner grave ... (cf. archives des ml open)
J'avoue que je ne vois pas comment compiler avec "-pthread" peut changer quelque chose sur des services qui n'utilisent pas les pthreads au départ. Je parle uniquement de ce qui fait partie de la base (sendmail, ftpd (donc inetd) et ssh dans les noms que tu as cités).
Tu utilisais un apache compilé à la main, curieux ...
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
Quand tu as recompilé tout pour que ça marche désormais, qu'as-tu recompilé ? Juste la libc_r, ou le noyau aussi ou tout ?
Ça ressemblait plus à une panne hard ou un driver buggé mais bon ...
D'autres gens ont eu un problème, un bon vieux "mb_map full", cf FAQ OpenBSD pour régler ça, et ça ne fait même pas tomber la machine, juste la rendre indisponible une demi-minute).
Perso je n'ai le problème sur aucune de mes deux machines (une en -current (x86, carte réseau "vr"), l'autre 2.9-stable (sparc, carte réseau "le")).
En general, un processus en attente d'un evenenement n'est pas actif (il est endormi).
Oui. Le souci (si c'en est un) c'est que tous les processus forment souvent une chaîne d'évenements (par ex. usbdaemon(souris) -> X11 -> [Window Manager ->] xbill).
Les user-threads ne sont pas interrompus. C'est de la pure coopération. Il y a des tas de hooks dans la libc qui appellent le scheduler par exemple.
Si tu as 5 threads qui font peu de choses, les 5 commutations peuvent se faire en 1 quantum de temps processeur dans le cas des user-threads, c'est tout.
En fait, ce qui est vraiment plus rapide en mode user (et surtout consomme beaucoup moins de ressources, descripteurs de process, etc. potentiellement limités) c'est la création (et la destruction) de threads. Les commutations de contexte sont aussi [un tout petit peu] plus lentes que les commutations en mode user.
Au final, les 2 méthodes ont leur avantages et leurs inconvénients (c'est en partie pour ça qu'une solution intermédiaire a été développée d'ailleurs).
La rapidité au final est très dépendante de l'application.
Pour revenir à la news de départ, c'est le fait de ne plus utiliser GNU pth qui réduit la charge cpu, pas la manière dont sont implémentés les threads.
J'ai beau lire un peu le site, je ne vois pas trop ce qu'est GNUStep. À mes débuts sous nunux, c'était pour moi le nom d'un répertoire crée par wmaker.
Aujourd'hui, l'idée que j'en ai est que c'est un truc-framework-machin dans la même mouvance que les systèmes de composants KDE et Gnome, hérité de NextStep et que Cocoa de MacOS X est partiellement basé dessus.
J'ai aussi l'idée que je me trompe lourdement.
Est-ce que quelqu'un qui connait bien tout ça peut faire un topo rapide ? (pour un décideur ;) )
Sur mon poste de travail par exemple, je pense que dans 99,9% des cas, le scheduleur, faute de concurrent, réaffecte le même processus au processeur.
Oui, mais non. Pour éviter la famine, plus un processus utilise le CPU et moins il peut l'utiliser (bon, si les autres n'en veulent pas ils ne le prennent pas mais ils passent quand même un peu de temps sur le CPU). En utilisation station de travail, il se passe toujours quelque chose : X11 en attente sur les évenements extérieurs à souvent la main, et les processus qui recoivent les évenements X11 aussi.
Ça fait au moins 2 processus : le serveur X et une xterm (par exemple, ça marche aussi avec getty et un shell). Et l'action de l'un fait réagir l'autre.
De toutes façons, par la construction même du scheduler, il y a quasiment toujours un concurrent (à moins qu'il n'y ai qu'un seul processus au total qui [puisse] tourner).
Je n'arrive pas trop à voir de cas « vrai monde réel » où un processus est schédulé deux fois de suite après avoir consommé tout son quantum de temps. Si on regarde en [1] et [2], les seuls cas possibles sont « un seul processus » et « tous les processus ont épuisé leur crédit temps ». Et même dans ce dernier cas, la structure de donnée (file) passe le plus ancien d'abord.
> Pour la TLB, au pire elle s'invalide toute seule.
Je ne comprends pas cette remarque. Elle est déclarée invalide lorsqu'on modifie le registre qui pointe sur la page des tables, ce n'est pas 'tout seul'.
Certes. En fait j'étais dans un autre délire (c'est le défaut de vouloir appliquer ce que l'on fait en ce moment à l'univers en général).
Au context-switch de processus il est nécessaire d'invalider la TLB (puisque chaque processus à son espace virtuel à lui). J'ai répondu trop vite et j'étais encore sur les threads en mode « user », donc je pensais que tu voulais invalider la TLB au thread switch pour que chaque thread aie son cache bien propre. Je fatigue parfois :)
Il n'y a quasiment jamais un seul processus actif. Même le noyau a des processus à lui (usbd, page daemon, swapper, etc.).
En fonctionnement normal (multi-user par opposition à single-user) tu as pleins de trucs qui tournent : getty, le shell, X11, syslogd ...
Pour ce qui est de la sauvegarde, il semblerait (à priori sur x86 et PPC, merci Kilobug pour m'avoir poussé à lire le code) que le processeur peut gérer ces sauvegardes presque tout seul, mais il sauvegarde quand même, ou tout du moins « laisse dans un coin ».
Pour la TLB, au pire elle s'invalide toute seule.
Au final, pas mal de processeurs modernes gèrent en partie ce genre de trucs. Cet aspect du noyau devient hyper-dépendant de la plateforme (bon, il l'a toujours été).
Pour windows, étant donné que c'est pas mal optimisé x86 (quoique le "vieux" port alpha devait pas être mal), je suppose qu'ils font le même genre de chose, ou peut-être utilisent-ils le système intégré au CPU dont parlent les commentaires dans le source de Linux.
Qu'on fasse le switch en user-space ou par le noyeau ce qu'il y a à faire est à peu près la même chose non ?
Oui, à peu près.
je concois mal que le noyeau aille alors moins vite que du code en user space. Il doit surement y avoir des choses faites en trop puisque vous semblez d'accord, lesquelles ?
Comme l'a dit pBpG plus haut, le noyau tourne aussi vite que le reste, ce qui est coûteux c'est le guichet pour passer de mode user à mode noyau.
En gros : pour passer dans le noyau tu laches une interruption, le handler sauvegarde tout le contexte, recharge celui du noyau, fait sa sauce, appelle l'ordonnanceur pour savoir sur qui retomber en sortie, recharge le processus décidé comme suivant et sort du noyau.
Dans le cas de threads au sein d'un même processus, il y a sauvegarde du contexte, chargement du suivant, point.
Ce qui est encore plus couteux quand on est en mode noyau c'est la création de processus : il faut choper une entrée de processus libre, mmap-er tous les segments de mémoire qui vont bien, le mettre dans la file du scheduler, etc. Pour le détruire, pareil, il faut libérer toutes ses ressources, etc. Sans compter que chaque passage dans le noyau est un passage dans l'ordonnanceur global et que le processus perd donc la main. Dans le cas du mode utilisateur tu à juste à créer un nouveau contexte local et te lancer dessus.
Dans le cas d'applis qui utilisent massivement les threads au sens création/destruction les threads user peuvent être plus intéressants que les processus.
[Je suppose que l'on parle bien de threads en mode utilisateur]
Sinon, pour ton exemple, mon exemple de départ n'était qu'un exemple (eh oui). Le comportement de l'ordonnanceur n'est pas défini dans la spec. Techniquement le passage au processus multithreadé donne la main à l'ordonnanceur local du processus qui gère ses threads comme il veut.
Pour reprendre ton schéma c'est (par exemple) :
A th1 (chgt ctx user) A th2 (chgt ctx KRNL) B (chgt ctx KRNL) A th2 (cght ctx user) A th1 ...
Au niveau du noyau, les processus sont en multi-tâche préemptif. Au niveau des threads (en mode user) c'est du multi-tâche coopératif. Le plus souvent les threads ne consomment pas tout le quantum de temps du processus, bien au contraire.
Une fois encore, il faut choisir son type de threads en fonction de l'appli. Plus un thread va être long et consommer des ressources et plus une solution orientée vers les processus va être intéressante. Plus une appli sera massivement multi-threadé avec beaucoup de threads à la vie courte et plus la solution « user-space » sera intéressante.
Note: sur une machine multi-processeur un processus ne tourne pas forcément toujours sur le même processeur.
Le processeur est une ressource comme les autres et est alloué dynamiquement.
On essaie effectivement de faire tourner le même code sur le même processeur le plus souvent pour maintenir une haute cohérence de cache mais dès qu'il y a changement de processus ce cache est « perdu », donc recharger un processus sur le même processeur n'apporterait rien (sauf applis spécifiques sur machines spécifiques avec caches sauvegardables et/ou lignes de caches monstrueuses).
Ensuite il y a plusieurs niveaux de threading. « user-space » où les threads se partagent le quantum de temps d'un seul processus, « kernel-based » où les threads sont autant de processus et les solutions intermédiaires où n threads se répartissent sur m processus et donc m quanta de temps processeur.
Mais ça n'a rien à voir avec le fait de tourner sur un processeur où un autre, le noyau alloue des laps de temps de calcul et se fout de savoir sur quel processeur ça tourne (sauf cas bien particuliers une fois encore).
Euh ... là il va falloir définir pthreads et threads natifs.
Les pthreads sont une interface de programmation.
En standard quand tu utilise cette interface ce sont les threads natifs d'OpenBSD qui sont utilisés. Le problème de charge avec MySQL tenait au fait que pour compenser certaines faiblesses de l'implémentation on utilise la librairie GNU pth qui pratique le spin-lock avec brio, d'où la montée en charge.
À peu près aucun service sous OpenBSD n'utilise pthreads. OpenSSH forke à l'ancienne, par exemple, et pour une bonne raison : il n'y a aucun besoin de communiquer entre les différents clients. Et c'est pareil pour quasiment tous les services. En plus la séparation de processus due au fork est plus rassurante que celle des pthreads (car ici ils sont user-space blabla -> voir thread du dessus) pour des services critiques.
Ton problème de charge venait plutôt de l'ancienne VM. De là à faire freezer le système, il devait y avoir un peu trop de trucs sur la machine et du hard mal configuré.
Ensuite ce genre de denial of service n'est pas spécifique à OpenBSD.
Appeler « poufs » des gamines de 5 ans dessinées style « Astro Boy » stylisé qui butent des monstres à grands coups de latte, je trouve ça curieux. Tu connais le dessin animé en question ?
Effectivement, après un petit surf, le terme LWP est défini différemment suivant les systèmes.
J'ai utilisé le terme LWP pour différentier l'approche 2 niveaux de Solaris de celles 1 niveau de Linux et OpenBSD, ce n'était pas une bonne idée.
Mais je maintiens qu'un context-switch d'un thread "noyau" est plus coûteux qu'un context-switch de threads "user" même si la différence est parfois minime. C'est la construction même du système qui veut ça.
Un thread "user" n'est pas forcément bloqué sur un accès disque, s'il y a des bons wrappers :).
De plus le coût de création/destruction est différent dans les deux cas (le cas "noyau" est plus coûteux une fois encore, plus de temps dans le noyau).
Au final, c'est un choix à faire en fonction de l'appli, comme d'habitude.
[Note: je parle de Linux standard, sans ajout de librairies spécialisées pour d'autres modèles d'ordonnancement]
[goto "Conclusion" pour les décideurs]
Oui mais pas vraiment des LWP.
Tu crée n processus qui partagent le même espace d'adressage mais qui sont des processus différents (on les voit avec ps). Ce qui est lourd c'est le context switch qui correspond à un passage dans le noyau plus diverses recopies de bidules et de machins.
Tu ne peux pas (encore une fois, je ne pouvais pas la dernière fois que j'ai essayé) avoir plusieurs threads au sein d'un seul processus. C'est à dire plusieurs fils d'éxécution dans un seul processus (toujours au sens noyau, visible par ps) (à moins d'utiliser GNU pth, peut-être, mais GNU pth, bon, si on peut éviter ...).
Les threads léger gèrent leur ordonnancement de manière interne au processus, sans passage dans le noyau, ce qui est moins couteux. Or Linux ne permet (permettait ?) pas de faire cela en standard.
Ce n'est pas une critique négative, ça a ses avantages aussi.
Ce ne sont pas des LWP, mais des threads « kernel-based » si on peut dire. La dénomination LWP est spécifique à Solaris et autres systèmes utilisant le même système de threading à 2 niveau (IRIX notamment (en tout cas sur la dernière Onyx que j'ai touchée), d'autres à vérifier).
Bref, ce ne sont pas des LWP (ça j'en suis sûr), et la puissance de l'ordonnanceur est gratuite pour le développeur mais a un coût à l'utilisation : le guichet du noyau. Dans le cas des threads au niveau utilisateur (par ex, pthreads OpenBSD) il n'y a pas de passage dans le noyau, en contrepartie le quantum de temps pour chaque thread est plus réduit.
Exemples :
Un processus A avec 2 threads A1&A2,
Un autre processus B
------> t
Sous Linux (ou équivalent de ce point de vue) : |<- proc B ->|<- thr A1 ->|<- thr A2 ->|<- proc B ->| ...
Sous OpenBSD (ou équivalent de ce point de vue) : |<- proc B ->|<- proc A ->|<- proc B ->|...
avec sur le temps de A : |<-------- proc A ------->|
|<- thr A1 ->|<- thr A2 ->|
Sous Solaris on peut avoir 2 threads sur un processus noyau et 1 autre thread du même groupe sur un autre processus noyau :
|<------- un seul code ------->
|<-- proc A -->|<-- proc B -->|
|<-t1->|<-t2 ->|<-- thr 3 --->|
Conclusion :
La méthode style Solaris est pas mal pour les archis multi-processeurs (notamment le système de noeuds avec mémoire distribuée sur certaines machines SGI), bon compromis.
Sous Linux, comme le SMP est géré, la méthode est adaptée aussi. Sous OpenBSD, le SMP n'est pas (encore) géré donc la méthode est adaptée. Le jour où le SMP sera géré sous Open, les threads légers gérés au niveau utilisateur ne se répartiront pas les processeurs, il resteront sur un seul car un seul processus au sens du noyau existera.
MySQL était l'appli ayant le plus de problèmes avec les pthreads. À priori elle faisait appel à une routine qui bloquait tout un processus et ses threads contenus[1] au lieu de bloquer un seul thread (ça au milieu d'autres soucis).
GTK+ tourne super bien avec les threads natifs sur x86 depuis un bout de temps, par exemple.
Les threads sont encore relativement « en développement » sous Open, surtout sur les archis non-x86. Mais ça s'améliore très vite.
Le truc, c'est que comme toutes les archis n'ont pas un support parfait, les ports sont compilé avec un mix de pthreads natifs[2] et de GNU pth [3].
[1] Sous OpenBSD les threads sont gérés dans le user space. Ce sont plusieurs fils d'éxécution qui tournent dans un seul processus. L'ordonnancement est géré via des hooks dans la libc_r. L'avantage c'est que c'est très rapide et très peu couteux. Le défaut c'est quand il reste des bugs et qu'un thread bloque tous les autres à cause d'un appel à une fonction qui bloque un processus entier.
Sous Linux, c'est (était ?) différent. Les threads sont matérialisés par des processus lourds différents. Ils sont créés par des appels type clone(2) (on peut faire l'équivalent sous Open avec rfork()). L'avantage c'est qu'il n'y a pas ce genre de problèmes d'ordonnancement car le noyau fait préemption (puisque ce sont des processus séparés). Le défaut c'est que c'est plus coûteux et moins rapide (la commutation de contexte est plus lourde).
Il existe au moins une troisième voie : les LWP (Light-Weight Processes) à la Solaris où n threads sont répartis sur m processus avec n >= m.
Au risque de dériver en troll, l'exemple que j'ai donné fonctionne dans 99,9% des cas.
Je l'ai mis comme ça chez mes parents et ils n'ont eu aucun problème (sauf pour lancer un serveur counterstrike).
Bref, bloquage de tout entrant et autorisation de sortie de tout avec « keep-state » protège de la plupart des problèmes les utilisateurs lambda (sauf les problèmes de chevaux de Troye).
Si on lit l'abstract du brevet Apple, ça donne l'impression de couvrir le concept d'alpha channel, voire même celui de masque binaire.
Sur un des sites donnés dans le thread il doit y avoir un lien vers ce brevet et il couvre une méthode de construction d'image à partir d'autres images utilisant un masque binaire pour choisir laquelle des 2 images d'entrée mettre dans la sortie. C'est unpeu gonflé comme brevet (comme beaucoup d'autres, d'ailleurs).
Le problème avec le site que tu a donné c'est qu'il n'a pas de rapport direct avec les gens qui développe le standard PNG lui-même. Il semblerait que les créateurs du standard PNG ai assuré queent la patente ne porte sur rien en ce qui concerne au moins PNG.
[^] # Re: Sylpheed aussi
Posté par Jean-Yves B. . En réponse à la dépêche Quels standards pour la signature et le cryptage PGP des mails ?. Évalué à 4.
Ne gère pas non plus les STARTTLS correctement.
[^] # Re: Remote DoS
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 1.
J'avoue que je ne vois pas comment compiler avec "-pthread" peut changer quelque chose sur des services qui n'utilisent pas les pthreads au départ. Je parle uniquement de ce qui fait partie de la base (sendmail, ftpd (donc inetd) et ssh dans les noms que tu as cités).
Bon, voyons ce que tu as posté sur misc@open
http://marc.theaimsgroup.com/?l=openbsd-misc&m=99772739026605&a(...))
Sinon, après avoir lu ce que tu as posté ...
Tu utilisais un apache compilé à la main, curieux ...
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
Quand tu as recompilé tout pour que ça marche désormais, qu'as-tu recompilé ? Juste la libc_r, ou le noyau aussi ou tout ?
Ça ressemblait plus à une panne hard ou un driver buggé mais bon ...
D'autres gens ont eu un problème, un bon vieux "mb_map full", cf FAQ OpenBSD pour régler ça, et ça ne fait même pas tomber la machine, juste la rendre indisponible une demi-minute).
Perso je n'ai le problème sur aucune de mes deux machines (une en -current (x86, carte réseau "vr"), l'autre 2.9-stable (sparc, carte réseau "le")).
Tu devrais envoyer un vrai bug report chez open.
[^] # Re: Un seul processus actif ?
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à -1.
Oui. Le souci (si c'en est un) c'est que tous les processus forment souvent une chaîne d'évenements (par ex. usbdaemon(souris) -> X11 -> [Window Manager ->] xbill).
[-1, dipterophilie anale]
[^] # Re: LWPs, my mistake.
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 1.
Si tu as 5 threads qui font peu de choses, les 5 commutations peuvent se faire en 1 quantum de temps processeur dans le cas des user-threads, c'est tout.
En fait, ce qui est vraiment plus rapide en mode user (et surtout consomme beaucoup moins de ressources, descripteurs de process, etc. potentiellement limités) c'est la création (et la destruction) de threads. Les commutations de contexte sont aussi [un tout petit peu] plus lentes que les commutations en mode user.
Au final, les 2 méthodes ont leur avantages et leurs inconvénients (c'est en partie pour ça qu'une solution intermédiaire a été développée d'ailleurs).
La rapidité au final est très dépendante de l'application.
Pour revenir à la news de départ, c'est le fait de ne plus utiliser GNU pth qui réduit la charge cpu, pas la manière dont sont implémentés les threads.
[^] # Objective C
Posté par Jean-Yves B. . En réponse à la dépêche GNUStep reçoit de l'aide de VMWare. Évalué à 8.
Une intro rapide : http://homepage.mac.com/oudinetg/faire/objectivec.html(...)">http://homepage.mac.com/oudinetg/faire/objectivec.html(...(...))">http://homepage.mac.com/oudinetg/faire/objectivec.html(...(...(...)))
Le man d'ObjC/Cocoa : http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/(...)">http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/(...(...))">http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/(...(..(...)))
Cheat-code pour émuler l'héritage multiple : http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/5RunTim(...)">http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/5RunTim(...))">http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/5RunTim(...)))
Bref, bizarre.
Pas d'héritage multiple.
Un système de passage de messages intéressant.
Pas mal d'introspection possible.
Je vais regarder tout ça un peu plus tard ...
[^] # Re: Quelqu'un pour un topo sur (GNU|Open)Step ?
Posté par Jean-Yves B. . En réponse à la dépêche GNUStep reçoit de l'aide de VMWare. Évalué à 6.
Sinon, est-ce très utilisé ? (non, ce n'est pas un troll, juste une question)
# Quelqu'un pour un topo sur (GNU|Open)Step ?
Posté par Jean-Yves B. . En réponse à la dépêche GNUStep reçoit de l'aide de VMWare. Évalué à 10.
Aujourd'hui, l'idée que j'en ai est que c'est un truc-framework-machin dans la même mouvance que les systèmes de composants KDE et Gnome, hérité de NextStep et que Cocoa de MacOS X est partiellement basé dessus.
J'ai aussi l'idée que je me trompe lourdement.
Est-ce que quelqu'un qui connait bien tout ça peut faire un topo rapide ? (pour un décideur ;) )
[^] # Re: Un seul processus actif ?
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 2.
Oui, mais non. Pour éviter la famine, plus un processus utilise le CPU et moins il peut l'utiliser (bon, si les autres n'en veulent pas ils ne le prennent pas mais ils passent quand même un peu de temps sur le CPU). En utilisation station de travail, il se passe toujours quelque chose : X11 en attente sur les évenements extérieurs à souvent la main, et les processus qui recoivent les évenements X11 aussi.
Ça fait au moins 2 processus : le serveur X et une xterm (par exemple, ça marche aussi avec getty et un shell). Et l'action de l'un fait réagir l'autre.
Le cas « un seul processus à besoin de tourner » est très improbable. L'optimisation est dans le noyau linux mais est marquée « unlikely », cf .http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L624(...)">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L624(...(...))">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L624(...(...(...)))
De toutes façons, par la construction même du scheduler, il y a quasiment toujours un concurrent (à moins qu'il n'y ai qu'un seul processus au total qui [puisse] tourner).
Je n'arrive pas trop à voir de cas « vrai monde réel » où un processus est schédulé deux fois de suite après avoir consommé tout son quantum de temps. Si on regarde en [1] et [2], les seuls cas possibles sont « un seul processus » et « tous les processus ont épuisé leur crédit temps ». Et même dans ce dernier cas, la structure de donnée (file) passe le plus ancien d'abord.
Certes. En fait j'étais dans un autre délire (c'est le défaut de vouloir appliquer ce que l'on fait en ce moment à l'univers en général).
Au context-switch de processus il est nécessaire d'invalider la TLB (puisque chaque processus à son espace virtuel à lui). J'ai répondu trop vite et j'étais encore sur les threads en mode « user », donc je pensais que tu voulais invalider la TLB au thread switch pour que chaque thread aie son cache bien propre. Je fatigue parfois :)
[1] http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L161(...)">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L161(...(...))">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L161(...(...(...)))
[2] http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L596(...)">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L596(...(...))">http://lxr.linux.no/source/kernel/sched.c?v=2.4.16#L596(...(...(...)))
[^] # Re: est-ce vraiment utile?
Posté par Jean-Yves B. . En réponse à la dépêche traduction LFS : on a besoin de vous!. Évalué à 10.
[^] # Un seul processus actif ?
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 4.
En fonctionnement normal (multi-user par opposition à single-user) tu as pleins de trucs qui tournent : getty, le shell, X11, syslogd ...
Pour ce qui est de la sauvegarde, il semblerait (à priori sur x86 et PPC, merci Kilobug pour m'avoir poussé à lire le code) que le processeur peut gérer ces sauvegardes presque tout seul, mais il sauvegarde quand même, ou tout du moins « laisse dans un coin ».
Pour la TLB, au pire elle s'invalide toute seule.
Au final, pas mal de processeurs modernes gèrent en partie ce genre de trucs. Cet aspect du noyau devient hyper-dépendant de la plateforme (bon, il l'a toujours été).
[^] # Re: Curieuse alternative
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 2.
Je travaille sur un système de processeur avec bus infini et registres d'addressage infinis.
On fait moins les malins, hein ? Tous les brevets sont posés, je n'ai plus qu'a ramasser le fric.
[Même pas -1, si on peut plus déconner]
[^] # Re: LWPs, my mistake.
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 3.
Effectivement, je vient de surfer un peu et c'est le proc qui fait le plus de boulot.
Sur PPC c'est un peu plus lisible, moins d'assembleur (j'ai regardé sur le 2.4.16).
Mais cet aspect semble le plus optimisé sur x86 en tout cas.
Il reste la création et destruction de processus comme consommateur de temps.
Pour comparer avec un switch de thread user sur i386 => http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc_r/arch/i386/uthr(...)">http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc_r/arch/i386/uthr(...))">http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc_r/arch/i386/uthr(...)))
et le code du scheduler => http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc_r/uthread/uthrea(...)">http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc_r/uthread/uthrea(...))">http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc_r/uthread/uthrea(...)))
C'est super bien commenté dans les deux cas (Linux et Open).
<pub>
Pour surfer sur le source du noyau Linux, ayez le réflexe LXR => http://lxr.linux.no/source/(...)">http://lxr.linux.no/source/(...(...))">http://lxr.linux.no/source/(...(...(...)))
</pub>
Pour windows, étant donné que c'est pas mal optimisé x86 (quoique le "vieux" port alpha devait pas être mal), je suppose qu'ils font le même genre de chose, ou peut-être utilisent-ils le système intégré au CPU dont parlent les commentaires dans le source de Linux.
[^] # Les threads, ces êtres incompris :)
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 5.
Oui, à peu près.
Comme l'a dit pBpG plus haut, le noyau tourne aussi vite que le reste, ce qui est coûteux c'est le guichet pour passer de mode user à mode noyau.
En gros : pour passer dans le noyau tu laches une interruption, le handler sauvegarde tout le contexte, recharge celui du noyau, fait sa sauce, appelle l'ordonnanceur pour savoir sur qui retomber en sortie, recharge le processus décidé comme suivant et sort du noyau.
Dans le cas de threads au sein d'un même processus, il y a sauvegarde du contexte, chargement du suivant, point.
Ce qui est encore plus couteux quand on est en mode noyau c'est la création de processus : il faut choper une entrée de processus libre, mmap-er tous les segments de mémoire qui vont bien, le mettre dans la file du scheduler, etc. Pour le détruire, pareil, il faut libérer toutes ses ressources, etc. Sans compter que chaque passage dans le noyau est un passage dans l'ordonnanceur global et que le processus perd donc la main. Dans le cas du mode utilisateur tu à juste à créer un nouveau contexte local et te lancer dessus.
Dans le cas d'applis qui utilisent massivement les threads au sens création/destruction les threads user peuvent être plus intéressants que les processus.
[Je suppose que l'on parle bien de threads en mode utilisateur]
Sinon, pour ton exemple, mon exemple de départ n'était qu'un exemple (eh oui). Le comportement de l'ordonnanceur n'est pas défini dans la spec. Techniquement le passage au processus multithreadé donne la main à l'ordonnanceur local du processus qui gère ses threads comme il veut.
Pour reprendre ton schéma c'est (par exemple) :
A th1 (chgt ctx user) A th2 (chgt ctx KRNL) B (chgt ctx KRNL) A th2 (cght ctx user) A th1 ...
Au niveau du noyau, les processus sont en multi-tâche préemptif. Au niveau des threads (en mode user) c'est du multi-tâche coopératif. Le plus souvent les threads ne consomment pas tout le quantum de temps du processus, bien au contraire.
Une fois encore, il faut choisir son type de threads en fonction de l'appli. Plus un thread va être long et consommer des ressources et plus une solution orientée vers les processus va être intéressante. Plus une appli sera massivement multi-threadé avec beaucoup de threads à la vie courte et plus la solution « user-space » sera intéressante.
[^] # Re: Autres applis et pthreads
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 4.
Le processeur est une ressource comme les autres et est alloué dynamiquement.
On essaie effectivement de faire tourner le même code sur le même processeur le plus souvent pour maintenir une haute cohérence de cache mais dès qu'il y a changement de processus ce cache est « perdu », donc recharger un processus sur le même processeur n'apporterait rien (sauf applis spécifiques sur machines spécifiques avec caches sauvegardables et/ou lignes de caches monstrueuses).
Ensuite il y a plusieurs niveaux de threading. « user-space » où les threads se partagent le quantum de temps d'un seul processus, « kernel-based » où les threads sont autant de processus et les solutions intermédiaires où n threads se répartissent sur m processus et donc m quanta de temps processeur.
Mais ça n'a rien à voir avec le fait de tourner sur un processeur où un autre, le noyau alloue des laps de temps de calcul et se fout de savoir sur quel processeur ça tourne (sauf cas bien particuliers une fois encore).
[^] # Re: Remote DoS
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 4.
Les pthreads sont une interface de programmation.
En standard quand tu utilise cette interface ce sont les threads natifs d'OpenBSD qui sont utilisés. Le problème de charge avec MySQL tenait au fait que pour compenser certaines faiblesses de l'implémentation on utilise la librairie GNU pth qui pratique le spin-lock avec brio, d'où la montée en charge.
À peu près aucun service sous OpenBSD n'utilise pthreads. OpenSSH forke à l'ancienne, par exemple, et pour une bonne raison : il n'y a aucun besoin de communiquer entre les différents clients. Et c'est pareil pour quasiment tous les services. En plus la séparation de processus due au fork est plus rassurante que celle des pthreads (car ici ils sont user-space blabla -> voir thread du dessus) pour des services critiques.
Ton problème de charge venait plutôt de l'ancienne VM. De là à faire freezer le système, il devait y avoir un peu trop de trucs sur la machine et du hard mal configuré.
Ensuite ce genre de denial of service n'est pas spécifique à OpenBSD.
EOT - End Of Troll
[^] # [Ultra-OT] Power-Poufs ??
Posté par Jean-Yves B. . En réponse à la dépêche Is Embedded Linux a bust?. Évalué à 0.
http://www.powerpuffgirls.com(...)
Au fait, aussi curieux que cela puisse paraître, ça ne fonctionne pas trop mal en France.
[-1, parce que les coups et les douleurs ...]
[^] # Re: Re : une question d'education
Posté par Jean-Yves B. . En réponse à la dépêche Linux est-il enfin prêt pour les virus?. Évalué à 5.
[^] # LWPs, my mistake.
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 10.
J'ai utilisé le terme LWP pour différentier l'approche 2 niveaux de Solaris de celles 1 niveau de Linux et OpenBSD, ce n'était pas une bonne idée.
Mais je maintiens qu'un context-switch d'un thread "noyau" est plus coûteux qu'un context-switch de threads "user" même si la différence est parfois minime. C'est la construction même du système qui veut ça.
Un thread "user" n'est pas forcément bloqué sur un accès disque, s'il y a des bons wrappers :).
De plus le coût de création/destruction est différent dans les deux cas (le cas "noyau" est plus coûteux une fois encore, plus de temps dans le noyau).
Au final, c'est un choix à faire en fonction de l'appli, comme d'habitude.
Un papier sur le multi-threading qui peut intéresser des gens, pour peser le pour et le contre des différentes implémentation (page 4, par exemple) :
ftp://menaik.cs.ualberta.ca/pub/TechReports/1995/TR95-23/TR95-23.p(...)
[promis, la prochaine fois je followupe en privé pour ne pas emmerder tout le monde]
[^] # Re: Autres applis et pthreads
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 10.
[goto "Conclusion" pour les décideurs]
Oui mais pas vraiment des LWP.
Tu crée n processus qui partagent le même espace d'adressage mais qui sont des processus différents (on les voit avec ps). Ce qui est lourd c'est le context switch qui correspond à un passage dans le noyau plus diverses recopies de bidules et de machins.
Tu ne peux pas (encore une fois, je ne pouvais pas la dernière fois que j'ai essayé) avoir plusieurs threads au sein d'un seul processus. C'est à dire plusieurs fils d'éxécution dans un seul processus (toujours au sens noyau, visible par ps) (à moins d'utiliser GNU pth, peut-être, mais GNU pth, bon, si on peut éviter ...).
Les threads léger gèrent leur ordonnancement de manière interne au processus, sans passage dans le noyau, ce qui est moins couteux. Or Linux ne permet (permettait ?) pas de faire cela en standard.
Ce n'est pas une critique négative, ça a ses avantages aussi.
Ce ne sont pas des LWP, mais des threads « kernel-based » si on peut dire. La dénomination LWP est spécifique à Solaris et autres systèmes utilisant le même système de threading à 2 niveau (IRIX notamment (en tout cas sur la dernière Onyx que j'ai touchée), d'autres à vérifier).
Bref, ce ne sont pas des LWP (ça j'en suis sûr), et la puissance de l'ordonnanceur est gratuite pour le développeur mais a un coût à l'utilisation : le guichet du noyau. Dans le cas des threads au niveau utilisateur (par ex, pthreads OpenBSD) il n'y a pas de passage dans le noyau, en contrepartie le quantum de temps pour chaque thread est plus réduit.
Exemples :
Un processus A avec 2 threads A1&A2,
Un autre processus B
------> t
Sous Linux (ou équivalent de ce point de vue) :
|<- proc B ->|<- thr A1 ->|<- thr A2 ->|<- proc B ->| ...
Sous OpenBSD (ou équivalent de ce point de vue) :
|<- proc B ->|<- proc A ->|<- proc B ->|...
avec sur le temps de A :
|<-------- proc A ------->|
|<- thr A1 ->|<- thr A2 ->|
Sous Solaris on peut avoir 2 threads sur un processus noyau et 1 autre thread du même groupe sur un autre processus noyau :
|<------- un seul code ------->
|<-- proc A -->|<-- proc B -->|
|<-t1->|<-t2 ->|<-- thr 3 --->|
Conclusion :
La méthode style Solaris est pas mal pour les archis multi-processeurs (notamment le système de noeuds avec mémoire distribuée sur certaines machines SGI), bon compromis.
Sous Linux, comme le SMP est géré, la méthode est adaptée aussi. Sous OpenBSD, le SMP n'est pas (encore) géré donc la méthode est adaptée. Le jour où le SMP sera géré sous Open, les threads légers gérés au niveau utilisateur ne se répartiront pas les processeurs, il resteront sur un seul car un seul processus au sens du noyau existera.
J'éspère ne pas avoir fait de fautes.
[^] # [OT] Jargon de gamer
Posté par Jean-Yves B. . En réponse à la dépêche Ryzom un jeu GPL. Évalué à 2.
[^] # Autres applis et pthreads
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 10.
GTK+ tourne super bien avec les threads natifs sur x86 depuis un bout de temps, par exemple.
Les threads sont encore relativement « en développement » sous Open, surtout sur les archis non-x86. Mais ça s'améliore très vite.
Le truc, c'est que comme toutes les archis n'ont pas un support parfait, les ports sont compilé avec un mix de pthreads natifs[2] et de GNU pth [3].
[1] Sous OpenBSD les threads sont gérés dans le user space. Ce sont plusieurs fils d'éxécution qui tournent dans un seul processus. L'ordonnancement est géré via des hooks dans la libc_r. L'avantage c'est que c'est très rapide et très peu couteux. Le défaut c'est quand il reste des bugs et qu'un thread bloque tous les autres à cause d'un appel à une fonction qui bloque un processus entier.
Sous Linux, c'est (était ?) différent. Les threads sont matérialisés par des processus lourds différents. Ils sont créés par des appels type clone(2) (on peut faire l'équivalent sous Open avec rfork()). L'avantage c'est qu'il n'y a pas ce genre de problèmes d'ordonnancement car le noyau fait préemption (puisque ce sont des processus séparés). Le défaut c'est que c'est plus coûteux et moins rapide (la commutation de contexte est plus lourde).
Il existe au moins une troisième voie : les LWP (Light-Weight Processes) à la Solaris où n threads sont répartis sur m processus avec n >= m.
[2] http://www.openbsd.org/cgi-bin/man.cgi?query=pthreads(...)
[3] http://www.gnu.org/software/pth/(...)
[^] # Re: Fonctionnalités recherchées par les entreprises
Posté par Jean-Yves B. . En réponse à la dépêche Une solution firewall Opensource. Évalué à 3.
Je l'ai mis comme ça chez mes parents et ils n'ont eu aucun problème (sauf pour lancer un serveur counterstrike).
Bref, bloquage de tout entrant et autorisation de sortie de tout avec « keep-state » protège de la plupart des problèmes les utilisateurs lambda (sauf les problèmes de chevaux de Troye).
[^] # Re: A noter
Posté par Jean-Yves B. . En réponse à la dépêche Enregistrements de la conf de Richard Stallman à l'Assemblée Nationale. Évalué à 3.
Si on lit l'abstract du brevet Apple, ça donne l'impression de couvrir le concept d'alpha channel, voire même celui de masque binaire.
Sur un des sites donnés dans le thread il doit y avoir un lien vers ce brevet et il couvre une méthode de construction d'image à partir d'autres images utilisant un masque binaire pour choisir laquelle des 2 images d'entrée mettre dans la sortie. C'est unpeu gonflé comme brevet (comme beaucoup d'autres, d'ailleurs).
[^] # Re: A noter
Posté par Jean-Yves B. . En réponse à la dépêche Enregistrements de la conf de Richard Stallman à l'Assemblée Nationale. Évalué à 2.
Pour faire de l'animé avec des PNG il faut gérer l'animation en (Java|ECMA)script (comme pour les jpeg).
Le PNG animé s'appelle MNG et est un peu différent. Il n'est que peu supporté pour l'instant.
[^] # Re: A noter
Posté par Jean-Yves B. . En réponse à la dépêche Enregistrements de la conf de Richard Stallman à l'Assemblée Nationale. Évalué à 0.