> ... j'aurais déjà aimé profité des 2.6.9 et 2.6.10 sous debian ...
Le 2.6.10 est dans sid. Le 2.6.9 y a surement été avant.
> Dommage que debian ne mette pas à dispo les sources des
> différents noyaux patchés, histoire qu'on puisse nous même se les
> compiler sans problème.
Il est vraiment si difficile d'aller telecharger les sources toi-meme sur kernel.org ?
Sinon le petit utilitaire ketchup permet de recuperer automatiquement le dernier noyau -rc, -mm, .... Très utile.
> Infiniband, en plus d'être plus performant a également l'avantage
> d'être un standard, donc on n'est plus cantonné à un seul
> fournisseur.
C'est la théorie ça.
En pratique, il n'y a que Mellanox qui produit réellement du matériel.
Il y a pas mal "d'assembleurs" InfiniBand en quelque sorte. Mais au final c'est pas si différent de Quadrics et Myrinet qui sont les seuls a produire leur matériel respectif.
Au niveau performance, la bande passante annoncée (12x voire 30x, c'est à dire 3Go/s voire 7,5Go) est enorme mais completement inobservable en pratique puisque les bus d'entrées-sorties des machines actuelles ne supportent guere plus que ce que InfiniBand 4x promet.
Donc au final, en bande passante c'est pareil que Quadrics (qui reste la référence du marché).
En latence, c'est beaucoup moins bons que Quadrics et Myrinet (moins de 2 et 3us respectivement) alors qu'Infiniband passe difficilement sous les 5-6us.
SCI a quasiment disparu du marché depuis quelques années déjà.
> Augmenter la taille des pages etend la couverture de la TLB, et donc
> limite le nombre de Page Fault (zone virtuelle non decrite dans la
> TLB, ce qui necessite une serie d'acces en memoire, tres couteuse,
> permettant de trouver la description, si elle existe, Memoire Virtuelle > => Memoire Physique.
Non, un Page Fault, c'est quand la _page_ n'est pas présente en mémoire physique, c'est-à-dire quand elle a été swappée sur le disque.
Quand le traduction virtuelle=>physique n'est pas dans la TLB, c'est un Cache Miss comme dans n'importe quel cache, un TLB miss ici.
Un TLB Miss, c'est plusieurs accès mémoire donc c'est lent.
Un page fault, c'est un accès disque donc TRES TRES lent.
> > Apparement ca ne porte que sur l'extension 64bit d'AMD et ne fait
> qu'ettendre la taille memoire physique supporte.
>
> Les autres cpu 64bit suivront.
Non, ca n'a rien a voir avec le fait d'etre une architecture 32 ou 64 bits. Ca ne depend que du nombre de niveaux de table de pages supportés par le matériel.
Les processeurs intel en supportent 2 ou 3. Les anciennes archis 64bits generalement 3. L'Opteron d'AMD en supporte 4.
Le noyau a donc du passer en 4 niveaux logiciels pour utiliser la capacité des opterons au maximum.
Sur les autres architectures, on rend 1 ou 2 des 4 niveaux logiciels pipo pour n'utiliser que les 2 ou 3 niveaux materiels.
Ensuite, on choisit la taille de chaque niveau et de la page, en général autour de 10 car c'est un bon rapport performance/cout.
Par exemple, Linux sur Opteron choisit 12 bits pour les pages (4ko) et 9bits pour chacun des 4 niveaux. Cela donne 48bits d'adresse physique supportés (contre 39 avant si je ne m'abuse).
On peut donc utiliser 256To de RAM physique.
Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).
Oui en fait, beaucoup de développeurs se sont plaints de l'idée de Linus. Linus voulait surtout sortir un 2.6.impair et que les gens le testent pour faire un 2.6.pair bien stable.
Mais beaucoup de developpeurs pensent que les gens vont arreter de tester les 2.6.impair. Retour au probleme initial donc.
De plus, cela aurait imposé des delais d'attente plus grand pour tous les gens qui veulent soumettre des patchs.
Donc, Linus and co. ont finalement décidé de garder le modèle actuel en ajoutant une vraie branche 2.6.x.y comme cela avait été fait avec 2.6.8.1 pour fixer un enorme bug NFS.
Greg KH va (pour commencer) maintenir 2.6.11.x (et a deja sorti 2.6.11.1 ce soir).
La branche 2.6.x.y sera susceptible de recevoir tous les petits patchs fixant des choses vraiment importantes.
Des que 2.6.(x+1) sortira, la branche 2.6.x.y sera stoppée.
En fait, InfiniBand devait initialement remplacer le bus PCI mais ca a été abandonné. Desormais, c'est juste un réseau tres hautes
performances utilisées dans les grappes de calcul.
En gros, c'est 5-10 microsecondes et 1Go/s.
Mais pour cela, il faut utiliser un protocole et des applications très speciales.
Le vrai support de ce protocole natif haute performance ne sera probablement jamais inclu car il est trop intrusif et concerne tres peu de gens.
Là, ils ont simplement inclu dans le noyau le support du protocole IP pour ces cartes.
[^] # Re: Oui, mais ...
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 3.
Le 2.6.10 est dans sid. Le 2.6.9 y a surement été avant.
> Dommage que debian ne mette pas à dispo les sources des
> différents noyaux patchés, histoire qu'on puisse nous même se les
> compiler sans problème.
Il est vraiment si difficile d'aller telecharger les sources toi-meme sur kernel.org ?
Sinon le petit utilitaire ketchup permet de recuperer automatiquement le dernier noyau -rc, -mm, .... Très utile.
[^] # Re: InfiniBand...
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 4.
> d'être un standard, donc on n'est plus cantonné à un seul
> fournisseur.
C'est la théorie ça.
En pratique, il n'y a que Mellanox qui produit réellement du matériel.
Il y a pas mal "d'assembleurs" InfiniBand en quelque sorte. Mais au final c'est pas si différent de Quadrics et Myrinet qui sont les seuls a produire leur matériel respectif.
Au niveau performance, la bande passante annoncée (12x voire 30x, c'est à dire 3Go/s voire 7,5Go) est enorme mais completement inobservable en pratique puisque les bus d'entrées-sorties des machines actuelles ne supportent guere plus que ce que InfiniBand 4x promet.
Donc au final, en bande passante c'est pareil que Quadrics (qui reste la référence du marché).
En latence, c'est beaucoup moins bons que Quadrics et Myrinet (moins de 2 et 3us respectivement) alors qu'Infiniband passe difficilement sous les 5-6us.
SCI a quasiment disparu du marché depuis quelques années déjà.
[^] # Re: Il manque
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 4.
> limite le nombre de Page Fault (zone virtuelle non decrite dans la
> TLB, ce qui necessite une serie d'acces en memoire, tres couteuse,
> permettant de trouver la description, si elle existe, Memoire Virtuelle > => Memoire Physique.
Non, un Page Fault, c'est quand la _page_ n'est pas présente en mémoire physique, c'est-à-dire quand elle a été swappée sur le disque.
Quand le traduction virtuelle=>physique n'est pas dans la TLB, c'est un Cache Miss comme dans n'importe quel cache, un TLB miss ici.
Un TLB Miss, c'est plusieurs accès mémoire donc c'est lent.
Un page fault, c'est un accès disque donc TRES TRES lent.
[^] # Re: Il manque
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 4.
> qu'ettendre la taille memoire physique supporte.
>
> Les autres cpu 64bit suivront.
Non, ca n'a rien a voir avec le fait d'etre une architecture 32 ou 64 bits. Ca ne depend que du nombre de niveaux de table de pages supportés par le matériel.
Les processeurs intel en supportent 2 ou 3. Les anciennes archis 64bits generalement 3. L'Opteron d'AMD en supporte 4.
Le noyau a donc du passer en 4 niveaux logiciels pour utiliser la capacité des opterons au maximum.
Sur les autres architectures, on rend 1 ou 2 des 4 niveaux logiciels pipo pour n'utiliser que les 2 ou 3 niveaux materiels.
Ensuite, on choisit la taille de chaque niveau et de la page, en général autour de 10 car c'est un bon rapport performance/cout.
Par exemple, Linux sur Opteron choisit 12 bits pour les pages (4ko) et 9bits pour chacun des 4 niveaux. Cela donne 48bits d'adresse physique supportés (contre 39 avant si je ne m'abuse).
On peut donc utiliser 256To de RAM physique.
Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).
[^] # Re: oops pardon
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
Mais beaucoup de developpeurs pensent que les gens vont arreter de tester les 2.6.impair. Retour au probleme initial donc.
De plus, cela aurait imposé des delais d'attente plus grand pour tous les gens qui veulent soumettre des patchs.
Donc, Linus and co. ont finalement décidé de garder le modèle actuel en ajoutant une vraie branche 2.6.x.y comme cela avait été fait avec 2.6.8.1 pour fixer un enorme bug NFS.
Greg KH va (pour commencer) maintenir 2.6.11.x (et a deja sorti 2.6.11.1 ce soir).
La branche 2.6.x.y sera susceptible de recevoir tous les petits patchs fixant des choses vraiment importantes.
Des que 2.6.(x+1) sortira, la branche 2.6.x.y sera stoppée.
# InfiniBand, c'est un réseau pour grappes
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 10.
performances utilisées dans les grappes de calcul.
En gros, c'est 5-10 microsecondes et 1Go/s.
Mais pour cela, il faut utiliser un protocole et des applications très speciales.
Le vrai support de ce protocole natif haute performance ne sera probablement jamais inclu car il est trop intrusif et concerne tres peu de gens.
Là, ils ont simplement inclu dans le noyau le support du protocole IP pour ces cartes.