Oui, il s'agit de problèmes d'ordonnancement, mais c'est quelque chose d'extrêmement important quand on parle processus/threads, tu en conviendras.
Oui et non, c'est un boulot d'OS ça.
Que tu utilises une règle genre n+2 threads, avec n == nombre de cpu et que tu charges chaque thread me semble correct. Le +2 est là pour masquer les ios.
Plusieurs fois, j'ai lu sur kernel trap ou la lkml que des gens avaient essayé de rajouter des extentions au scheduler linux pour visser un thread à un cpu. A chaque fois, les performances étaient en baissent pour de sombre histoire de gestion d'interruption.
Bref, si tu as une machine linux avec qq centaines de processeurs, je laisserais faire l'OS.
Je n'imagine pas faire du scheduling à la main pour des raisons de "thoughput" (de bande passante), si on en trouve encore c'est pour des raisons de latence, lié à des contraintes temps réel.
[^] # Re: Le fortran
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'est-ce qu'un langage sécurisé ?. Évalué à 2.
Oui et non, c'est un boulot d'OS ça.
Que tu utilises une règle genre n+2 threads, avec n == nombre de cpu et que tu charges chaque thread me semble correct. Le +2 est là pour masquer les ios.
Plusieurs fois, j'ai lu sur kernel trap ou la lkml que des gens avaient essayé de rajouter des extentions au scheduler linux pour visser un thread à un cpu. A chaque fois, les performances étaient en baissent pour de sombre histoire de gestion d'interruption.
Bref, si tu as une machine linux avec qq centaines de processeurs, je laisserais faire l'OS.
Je n'imagine pas faire du scheduling à la main pour des raisons de "thoughput" (de bande passante), si on en trouve encore c'est pour des raisons de latence, lié à des contraintes temps réel.
"La première sécurité est la liberté"