Le problème a été résolu dans le -current (post OpenBSD 3.0) en utilisant les threads natifs de l'OS et non plus les threads pth. Ainsi un serveur MySQL bien chargé utilise en moyenne 60 à 70% de CPU avec ces derniers alors qu'après modification (-current), il tourne autour de ...7% !!!
Le howto donné en lien explique très bien comment faire pour baisser la consommation CPU de MySQL. Mais attention, vous aurez comme résultat un OpenBSD 3.0 avec un peu de current dedans. Potentiellement, ceci pourrait causer des problèmes avec d'autres applications.
Aller plus loin
- howto (6 clics)
# Curieuse alternative
Posté par VACHOR (site web personnel) . Évalué à 10.
Pour rappel, une machine stable est éteinte, ou alors une application stable est une appli bien codée s'appuyant sur système fiable, le tout sur du hardware stable, voir aussi sur un réseau stable.
Parce que l'allocation mémoire aléatoire de l'histoire des pingouins, ca va vite mais ca marche pas longtemps...
[^] # Re: Curieuse alternative
Posté par saad . Évalué à 10.
Et comme on peut le lire souvent sur misc@openbsd.org: how stable is -current ? very stable.
[^] # Autres applis et pthreads
Posté par Jean-Yves B. . É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: Autres applis et pthreads
Posté par Gaël Le Mignot . Évalué à 10.
Il n'y aucune lourdeur là-dedans, et on bénéficie de la puissance de l'ordonanceur du noyau "gratuitement". Le seul unique problème est qu'un processus créant 10 LWP aura potentiellement accès au CPU 10x plus souvent qu'un processus de même priorité et ne créant aucun LWP, mais on peut toujours contourner ça via nice().
[^] # Re: Autres applis et pthreads
Posté par Jean-Yves B. . É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.
[^] # Re: Autres applis et pthreads
Posté par Gaël Le Mignot . Évalué à 10.
La commutation de contexte n'est pas si coûteuse que ça et permet d'avoir tous les autres bénéfices de l'ordonnanceur du noyau (par exemple si un thread est bloqué sur un accès disque, le CPU peut être donné à un autre thread).
-1 car on est entrain de sortir le couteau à quadricapillectomie
[^] # LWPs, my mistake.
Posté par Jean-Yves B. . É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: LWPs, my mistake.
Posté par benja . Évalué à 9.
Nooon ! Surtout pas ! ;-)
Personnelement, c'est ce genre de commentaires que je vourdrais voir + souvent. Pas de commentaires polémiques mais simplement des commentaires qui vous apprennent quelque chose (tm).
[^] # Re: LWPs, my mistake.
Posté par bmc . Évalué à 3.
[^] # Re: LWPs, my mistake.
Posté par pasBill pasGates . Évalué à 0.
Un process a un certain nombre de donnees qui lui sont propres du genre signal handler, tables des pages memoire, registres, stack frame, etc...
Quand le noyau fait le scheduling, tu sauvegarde certaines de ces donnees quelque part car elles vont etre remplacees par celles du prochain processus(a ce moment t'as aucune idee si le prochain thread sera du meme process qu'avant ou d'un autre process, donc t'es oblige de tout sauver), c'est le context-switch au niveau kernel.
Quand le scheduling se fait en user-mode entre threads, les threads ont un certain nombre de ces donnees en commun, notamment la table des pages memoire, et n'ont pas besoin de sauver/restorer ces donnees car il est certain que le thread schedule sera du meme process, d'ou gain de temps.
[^] # Re: LWPs, my mistake.
Posté par Sébastien Koechlin . Évalué à 2.
Je ne crois pas que ce soit le comportement de Linux 2.2 ni de 2.4.
Très souvent, il n'y a qu'un processus actif, or dans ce cas, la sauvegarde est du temps perdu. Linux ne change tous les paramêtres (pointeurs vers de descripteur des taches, pages mémoires...) que lorsque c'est un nouveau processus différent qui prends la main. Dans le cas des threads, je ne suis même pas sur que le noyau invalide le TLB.
Le sur-coût est plutot lié au fait que l'on salit le cache du processeur avec tout le code noyau exécuté.
[^] # Un seul processus actif ?
Posté par Jean-Yves B. . É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: Un seul processus actif ?
Posté par Sébastien Koechlin . Évalué à 3.
Je n'ai peut-être pas utilisé le bon vocabulaire, par processus actif, j'entends un processus en mode 'Runnable', un processus qui n'est pas bloqué par un appel système et succeptible de consommer du CPU.
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.
Pour ce qui est de la sauvegarde, il semblerait que le processeur peut gérer ces sauvegardes presque tout seul
Le 386 et les processeurs compatibles sont effectivement conçus pour cela, ils font tout le boulot si on accepte le cadre de fonctionnement proposé par intel. Je pense que c'est pour cela que Linus à dit que Linux n'était pas portable (du temps des Linux 0.x); il s'est beaucoup appuyé au début sur tous les mécanismes automatiques d'Intel.
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'.
[^] # Re: Un seul processus actif ?
Posté par Jean-Yves B. . É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: Un seul processus actif ?
Posté par Johann Deneux . Évalué à 2.
Il y a des cas ou on est oblige de faire de l'attente active (=tester un registre, par exemple), mais c'est en general a eviter comme la peste.
[^] # Re: Un seul processus actif ?
Posté par Jean-Yves B. . É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 Gaël Le Mignot . Évalué à 5.
Sur i386, il change le valeur du registre ldtr (qui indique quelle Local Descriptor Table utiliser), ainsi que la valeur du pointer "current" qui contient toutes les données nécessaires pour le processus.
Les étapes les plus longues dans la commutation sont la sauvegarde/restauration des registres (d'ailleurs Linux réalise là aussi une économie en ne s'occupant des registres FPU que lorsqu'ils sont utilisés) et le basculement mode utilisateur/mode noyau (qui se fait pour chaque appel système).
Poru plus d'informations voir le fichier arch/i386/kernel/process.c (fonction __switch_to) et le fichier include/asm-i386/system.h (macro switch_to).
Donc oui, une commutation noyau est sans doute plus coûteuse qu'une commutation en user-space, mais pas tant que ça (sous Linux en tout cas).
[^] # Re: LWPs, my mistake.
Posté par Jean-Yves B. . É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.
[^] # Re: LWPs, my mistake.
Posté par Johann Deneux . Évalué à 2.
La difference serait donc que les user-threads peuvent etre reschedules plus souvent que ceux du noyau. Mais finalement, on perd moins de temps avec un scheduling par le noyau.
Pour resumer: les user-threads sont interrompus par le scheduler user-mode et le scheduler du noyau, les pthreads linux uniquement par le scheduler du noyau. Pourquoi la 1ere solution serait-elle plus rapide ?
[^] # Re: LWPs, my mistake.
Posté par Jean-Yves B. . É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.
[^] # Re: LWPs, my mistake.
Posté par Éric (site web personnel) . Évalué à 3.
C'est tellement rare que je me demande quand est ce qu'était la dernière fois où j'ai eu plaisir comme ca à lire les commentaires, pour une fois ils sont utiles.
Au contraire, il faudrait en voir plus souvent (ou alors mettez mon adresse mail dans le follow-up :)
2/ Bon, je suis plus qu'inexpérimenté en la matière, je ne connais que la théorie (et encore, c'est flou). Par contre je me pose une question :
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 ? 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 ?
Dans le même esprit :
Si on avait des switch que entre les threads je comprend que il puisse y avoir avantage (si effectivement le noyeau fait trop de choses lors d'un switch). Sauf que en fait le noyeau va rester peu de temps sur le processus à chaque fois donc va de toute facon faire des changements de contexte très souvent, à partir du moment où il change de contexte autant faire en sorte quand il le fait qu'on arrive directement sur le thread suivant (thread au niveau noyeau, puisque ce sont des processus différents) au lieu d'arriver toujours sur le meme et de redoubler le changement de contexte pour changer de thread dans le processus (méthode thread user space).
Bon, j'ai du mal à m'exprimer alors un petit shéma :
Ath1 (chg de contexte noyeau) B (chg contexte noyeau) Ath2 .....
est logiquement plus interressant que :
A th1 (chg contexte noyeau) B (chg contexte noyeau) A (chg contexte user) th2 ....
J'ai l'impression qu'il y a deux chg alors qu'on pourrait en mettre un seul. J'ai fait une erreur ? j'ai mal compris un truc car là si j'ai compris il n'y a aucun interet à ne pas utiliser le noyeau pour les threads
[^] # Les threads, ces êtres incompris :)
Posté par Jean-Yves B. . É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 spim . Évalué à 2.
J'avoue que le fait que les threads d'une appli puissent venir polluer un processeur alloue a une autre appli sur une machine SMP c'est un poil bizarre.
Est ce que ce style d'implementation est aussi present sur les versions RT de linux ?
Si oui n'est ce pas a l'encontre des bases du Real Time (dans le sens ou un processeur est alloue a un processus) ?
[^] # Re: Autres applis et pthreads
Posté par pasBill pasGates . Évalué à 0.
Un thread qui viendrait sur le CPU ou une autre appli tourne, c'est que le scheduler a decide qu'il etait prioritaire sur l'appli qui tournait, donc il a une tres bonne raison de tourner. Si tu veux pas que ca arrive c'est tres simple: tu augmentes la priorite de l'application a laquelle tu tiens.
Un autre truc qui est lie mais un peu different c'est l'affinite d'un thread/process a un CPU:
- soft affinity: le thread tournera autant que possible toujours sur le(s) meme(s) CPU mais c'est pas garanti, ca permet au scheduler de mettre le thread sur un autre CPU si le CPU "elu" est tres occupe et qu'un autre est libre
- hard affinity: le thread est assure qu'il tournera toujours sur le(s) meme(s) CPU quoi qu'il arrive, ca peut servir pour certaines applications tres specifiques.
L'avantage ici c'est qu'il n'y a pas besoin de flusher/reloader les caches des CPU car les threads sont toujours sur le meme CPU.
Maintenant un des avantages des LWP c'est justement qu'une appli "mal eduquee" qui creerait 200 threads ne s'approprierait pas le CPU pour autant, car les threads seraient schedules dans 10 "threads normaux" qui eux sont schedules par le scheduler du kernel, resultat au lieu que le scheduler partage le temps dispo entre 200 + x threads, il le partage entre 10 +x threads, et les 10 threads partagent leur temps entre les 20 LWP de chaque thread.
[^] # Re: Autres applis et pthreads
Posté par spim . Évalué à 1.
Ca n'a rien de bizarre, c'est la meme chose sur toutes les plateformes.
Justement si.
Un thread est dependant d'un processus, il est donc normal de retrouver ce thread sur le cpu qui traite le processus dans le temps imparti pour ce processus.
Sinon autant faire que des forks avec des partages de ressources.
Enfin bon chui p'tet trop conservateur et vieux jeu :)
[^] # Re: Autres applis et pthreads
Posté par pasBill pasGates . Évalué à -1.
Les threads ont pas ete crees pour attendre a la queue l'un apres l'autre sur 1 CPU que le precedent finisse alors que 3 autres CPU se tournent les pouces mais pour faciliter la tache des devs(qui n'ont plus a s'occuper du partage de ressources a la main) et optimiser les context-switch/creation de processus tant que ce peut par rapport aux fork() + segments de memoire partage.
[^] # Re: Autres applis et pthreads
Posté par Jean-Yves B. . É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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Curieuse alternative
Posté par Laurent Buffler . Évalué à 10.
Seulement si la routine d'allocation utilise tout l'espace d'adressage. Ce qui veut dire générer un nombre aléatoire entre 0 et l'infini.... Certainement plus difficile et plus lent qu'une routine d'allocation de mémoire...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Curieuse alternative
Posté par Marc (site web personnel) . Évalué à -1.
aucun prob, ca te coutera +infini franc/euro...de toute facon ca change rien... A moins que qq1 connaisse le taux de change de l'infini franc en euro. =)
[^] # Re: Curieuse alternative
Posté par Obsidian . Évalué à -1.
C'est possible mais les délais de fabrication et le coût sont eux-aussi infinis, par contre on peut te livre en plusieurs fois.
Si t'es preneur préviens-moi, je crois que point de vue création d'entreprise, je tiens le filon pour une bonne cinquantaine d'années.
-1
[^] # Re: Curieuse alternative
Posté par shbrol . Évalué à -2.
(-1 aussi)
[^] # Re: Curieuse alternative
Posté par Jean-Yves B. . É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]
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Curieuse alternative
Posté par spim . Évalué à 2.
Il est tres rare d'avoir le -current casse plus de 20min.
<Joke>
Ca change de certains kernels :)
</joke>
[^] # Re: Curieuse alternative
Posté par Miod in the middle . Évalué à 1.
[-1 hors sujet]
# Remote DoS
Posté par Gilles Chehade . Évalué à 8.
La seule solution valable est la recompilation de tout les services en utilisant les threads natifs en lieu et place des pthreads.
Voila, c'etait le scoop qui parait chez vous avant ailleurs ;)
[^] # Re: Remote DoS
Posté par saad . Évalué à 10.
Je pense que n'importe quel OS (ou ASIC) est DoSable dans la mesure où on dispose des ressources suffisantes pour le faire planter. C'est pourquoi des données concrètes nous permetterait de trouver une parade si besoin. Ces données pourraient être soumises à la critique de Theo & the crew sur misc@ ou tech@. Qu'en penses-tu ?
[^] # Re: Remote DoS
Posté par Gilles Chehade . Évalué à 2.
>> methodologie ?
>> J'avais réalisé un executable qui effectuait
>> une simulation d'authentification puis se
>> déconnectait aussitot dans une boucle. Cet
>> executable a ete
>> envoyes à diverses personnes sur l'une des
>> mailing list d'OpenBSD il y a environ deux
>> mois de cela (peut-être un peu plus).
>> Pour les services on a essayé sur ftpd, proftpd
>> sendmail, postfix, cucipop, popa3d (pour ma
>> part) et probablement d'autres (je ne sais
>> pas ce qui faisait tourner les machines des
>> autres)...
as tu des chiffres (protocole de transport physique, vitesse de la connexion, nb de connexions simultanées, tcp ou udp ou icmp ou la combinaison) concrets à nous communiquer ?
>> les tests ont pour la plupart etes fait en
>> reseaux locaux sur des 10mb/s et des 100mb/s,
>> attention il ne s'agissait PAS de connexions
>> simultanées, mais de connexions les unes à la
>> suite des autres.
>> En fait, les chiffres étaient assez variables,
>> mais en envoyant en moyenne, 2 ou 3 milles
>> demandes de connexions par minutes, le serveur
>> plantait en 20/30 secondes (si tu as un doute
>> tu cherches dans les archives DoS, tu va voir
>> un thread avec les personnes qui ont testées
>> le denial).
>> Au niveau du protocole, de
>> mon coté c'etait du tcp, maintenant je sais
>> pas si quelqu'un a pas essayé en udp...
Je pense que n'importe quel OS (ou ASIC) est DoSable dans la mesure où on dispose des ressources suffisantes pour le faire planter.
>> Attention, la je parle bien de DoS sans trop
>> de ressources, ce qui fait peur...
C'est pourquoi des données concrètes nous permetterait de trouver une parade si besoin. Ces données pourraient être soumises à la critique de Theo & the crew sur misc@ ou tech@.
>> Déjà envoyés là bas depuis deux/trois mois.
Qu'en penses-tu ?
>> C'est une bonne idée ;)
[^] # Re: Remote DoS
Posté par spim . Évalué à 2.
Ca sent le bon troll des campagnes ...
[^] # Re: Remote DoS
Posté par Jean-Yves B. . É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
[^] # Re: Remote DoS
Posté par Gilles Chehade . Évalué à 1.
- OpenBSD toutes les versions supérieures à la 2.7 qu'elles soient en branche -base, -stable ou -current plantent, plus aucun problème une fois que l'on utilise les threads natifs (libc_r) qui sont actuellement dans la branche -current.
- NetBSD aucun bleme
- FreeBSD aucun bleme
J'ai beau adorer OpenBSD, si un bug est -spécifique- à cet OS, je n'ai rien à gagner en me disant le contraire.
[^] # Re: Remote DoS
Posté par Jean-Yves B. . É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: Remote DoS
Posté par Gilles Chehade . Évalué à 1.
>> vi, vi -pthread et -lc_r ;)
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.
> j'ai repris le terme employé je ne sais plus
> ou, quand je dis thread natifs, je ne parles
> plus des gnu pth.
Si tu me parles de GNU pth là je comprends un peu mieux.
> heh
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).
> j'ai pas ete voir les sources, je pense pas
> avoir le niveau (d'ailleurs non seulement je
> pense pas, mais en plus je suis SUR de ne pas
> l'avoir) pour aller voir pourquoi tel service
> merde quand il est compilé de telle ou telle
> facon. Marrant que tu parles d'inetd, j'ai pas
> essayé du tout inetd, tout tournait en
> standalone (du moins chez moi).
Bon, voyons ce que tu as posté sur misc@open
marc.theaimsgroup.com/?l=openbsd-misc&am
Sinon, après avoir lu ce que tu as posté ...
Tu utilisais un apache compilé à la main, curieux ...
> je suis pas un grand fan des ports ;)
Tu t'es fait éconduire car tu ne fournissait pas de détails ...
> tu doit pas lire le bon, le thread etait assez
> long, j'ai même fournit l'executable qui
> permettait de tester si la machine subissait
> le crash ou non.
>
> j'ai fait pas mal de post sur les mailing d'
> open, cherche encore ;)
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 ?
> j'ai d'abord recompilé libc_r, pis apres je me
> suis appercut que cette lib etait utilisée par
> pas mal d'autres libs, alors je me suis dit qu'
> il fallait recompiler toutes les libs, j'ai
> fait un gros make build. Mais comme j'ai lu a
> un moment KERNEL_PTHREAD lors d'une compilation
> j'en ai déduit que le kernel devait influencer
> donc... la totale.
Ç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).
> nan rien a voir, ca ca se corrige en optimisant
> le kernel ca. Meme en ayant optimisé à fond le
> kernel, on peut toujours crasher Open.
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")).
> on a été environ une 50aines à tester, 80% des
> personnes qui tournaient sous Open on subit le
> crash, que ce soit sur des i386, des sparcs,
> des alphas.
Tu devrais envoyer un vrai bug report chez open.
> c'est fait depuis un moment déjà, mais c'est
> plus la peine d'en faire un vu que ca a été
> apparemment corrigé dans -current.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.