L'architecture de bus InfiniBand est prise en charge dans ce nouveau noyau : c'est apparemment une alternative au bus PCI où les données sont transmises en série et en multiplexage, au lieu d'être transmises en parallèle, ceci ne concernant pour l'instant que les serveurs « high-end » et certains PC.
![[en]](../images/en.png)
Le noyau linux (1837 hits)-
InfiniBand (744 hits)
-
L'email d'annonce (764 hits)
-
2.6.11 sur kernaltrap (1290 hits)
-
ChangeLog (996 hits)
> Lire la dépêche (92 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #541456.
Run by 
Cette page a été générée par Templeet en 0.1291s (dont 0.0111 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Il manque
Euh, je pense qu'il manque tout de meme dans la description des changements apportés à cette release, le patch permettant d'utiliser des tables de pages à 4 niveaux permettant d'utiliser pleinement les architectures 64 bits.
Voilà, mes deux cents ;-) et je => []
- Christophe -
[^]Re: Il manque
Quelques infos sur le 2.6.11 :
Four-level page tables :
http://lwn.net/Articles/117749/(...)
Optimisation d'ext3 :
http://lwn.net/Articles/112566/(...)
Circular pipes (très interessant) :
http://lwn.net/Articles/118750/(...)
Big Kernel Semaphore :
http://lwn.net/Articles/102253/(...)
Merci à lwn pour ces excellents articles.
[^]Re: Il manque
Apparement ca ne porte que sur l'extension 64bit d'AMD et ne fait qu'ettendre la taille memoire physique supporte.
Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.
[^]Re: Il manque
> 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.
> Je serais beaucoup plus heureux lorsque cela integrera le support de taille de page variable.
???
à chaud ou via une recompilation du noyau ?
Pourquoi faire ?
[^]Re: Il manque
Les autres cpu 64bit suivront.
C'est mis au conditionel pour l'instant. Mais je ne faisais que dire que ce n'etait pas pour tous "aujourd'hui". Rien d'autre.
à chaud ou via une recompilation du noyau ?
Via recompilation noyau on sait deja faire. La gestion de taille de page variable est "live". En fait le gestionnaire choisit, par les fait, la taille de la page. Il peut decider de decomposer une grande page en plusieur, ou de le recomposer des plus petites en plus grandes.
La granularite se fait a la page elle-meme. Une meme application peut avoir plusieurs tailles de page.
Pourquoi faire ?
J'ai pas envie de rentrer dans la theorie. En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite. Aujourd'hui, pour les architectures qui supportent plusieurs taillent, tu imposes, a la compilation du noyau, une taille fixe pour tout le monde. Donc tu favorises une application par rapport a une autre. Le support de la gestion de page variables permet de:
- avoir la taille correcte pour chaque applications/zone de donnees
- Ne plus avoir a se poser la question lors de la compilation
Dans les deux cas, le Kernel s'occupe de tout.
[^]Re: Il manque
> Via recompilation noyau on sait deja faire.
Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).
> En gros, certaines applications fonctionnent mieux avec des pages plus grandes, d'autres fonctionnent mieux avec des pages plus petite.
Je dis pas non mais t'aurais un exemple concret ou un bench je te plusserais :-)
Puis c'est peut-être plus pertinent de faire ça côté libc si tu penses à l'optimisation de malloc/free. Un malloc n'aboutis pas systématique a un appel système "malloc" et beaucoup d'appels systèmes peuvent marcher sur une page mémoire (read, write, brk, etc).
Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
[^]Re: Il manque
Je ne suis pas convaincu que toutes les applis marchent après avoir changé PAGE_SIZE (qui est une macro définie dans /usr/include/asm/page.h).
Normalement une application ne doit pas se préoccuper de PAGE_SIZE ou de tout autre particularité de la mémoire virtuelle.
Au feeling, je n'ai pas l'impression que ça peut apporter un gain important.
Pour faire les conversions adresse mémoire virtuelle -> adresse physique, le processeur utilise un cache TLB (Translation Lookaside Buffer). A priori, je dirais que plus la taille des pages est grande, plus on peut stocker d'associations (adresse virtuelle, adresse physique) dans cette table. Mais je me trompe peut-être.
[^]Re: Il manque
> Normalement une application ne doit pas se préoccuper de PAGE_SIZE ou de tout autre particularité de la mémoire virtuelle.
Les man de mmap et mlock ne sont pas d'accord avec toi... Ok, la taille de page dont ils parlent ne correspond pas nécessairement à la taille de page réelle utilisée par le noyau, mais à mon avis à l'heure actuelle c'est le cas.
[^]Re: Il manque
Mouais, effectivement. Quoique mmap() parle plutôt de getpagesize() et mlock() de PAGESIZE définie dans <limits.h>
Quoiqu'il en soit, tant que tu respectes la contrainte imposée (offset multiple de PAGESIZE ou autre), tu te moques complètement de comment est réalisée l'implémentation derrière, et des particularités du CPU et de sa MMU. C'était le sens de mon message :)
[^]Re: Il manque
Euh, c'est pas vraiment le TLB qui fait la traduction d'adresses virtuelles en adresses physiques. C'est la MMU :-) Le TLB est comme son nom l'indique un cache permettant de trouver plus rapidement l'association pages virtuelles-pages physiques.
D'ailleurs au passage, le code gérant le TLB sur architecture PPC a été revu.
Bonne journée les gens...
- Christophe -
[+] [^]Re: Il manque
Bonjour, dans la série "j'apprends à lire":
"le processeur utilise un cache TLB"
[^]Re: Il manque
Bonjour,
J'ai bien compris merci et je sais très bien ce qu'est un cache TLB. Maintenant, si préciser réellement ce qui fait une traduction d'adresses virtuelles en adresses physiques est un crime, j'aurais peut-être dû me taire !
La phrase d'origine laissait penser que c'est le cache TLB qui fait cette traduction, je voulais juste souligner cela.
Bon bah je retourne apprendre à lire et => [].
- Christophe -
[^]Re: Il manque
Moui, enfin dans le cas présent le fait que le TLB ne soit qu'une partie du MMU n'a rien avoir avec la choucroute..
Comme dit plus haut une gestion par le noyeau de taille de page variable permettrait une meilleure utilisation du TLB, qui en général n'est pas bien gros..
J'ajouterai que le noyeau gère des listes qui décrivent l'utilisation des pages, avec les taille mémoires actuelles et des pages de 4k, la taille de ces structures est assez importantes..
Une gestion des pages avec une taille variable permettrait probablement de réduire la taille occupées par ces listes.
Le gain en performance se faisant problablement sentir sur les configurations avec beaucoup de mémoire.
[+] [^]Re: Il manque
pfffffffff
[+] [^]Re: Il manque
rien a voir avec la libc. tu devrais pouvoir changer pour une application la taille des pages pour les archi le supportant (pour la heap, la stack ou le code). On devrait pouvoir le faire pour une lib ou un process precis.
Quand au gains, j'ai vu certains scenario passer 50 % de leurs temps a convertir des adresses physiques en adresse virtuel en 32-bit (dependant de l'archi).
Je trouve desolant qu'actuellement, Linus passe plus de temps a faire des fixes pour les portable IBM qu'a developper serieusement. Les mecs de Debian et de Fedora devrait lui lacher la grappe.
Je trouve desolant aussi que l'on parle ENCORE de l'ACPI.
J'aime pas IBM.
[^]Re: Il manque
si tu penses à l'optimisation de malloc/free.
Je pense au fait qu'aujourd'hui, sur certaine machines, le cache est trop gros pour avoir une complete couverture par la TLB (lire dans le document de mon second lien).
Par "couverture", je parle de la traduction Memoire Virtuelle => Memoire Physique.
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.
Mais, augmenter la taille des pages peut etre a l'origine de gachis. Il suffit de penser a la taille de bloc dans les systemes de fichier. Plus c'est gros, plus tu as de chance de "perdre" de la memoire. Si une application n'a besoin que de 2Ko, tu perds moins de memoire en allouant 4ko au lieu de 16ko par exemple.
Quand je parle d'allocation, c'est pas malloc/free, mais dans la VM.
Bon quelques liens:
http://www.gelato.unsw.edu.au/IA64wiki/NPTLbenchmarks(...)
C'est plutot un bench qui a ete fait lors de l'implementation des NPTL. Mais par contre il montre l'influence de la taille d'une page.
http://www.cs.rice.edu/~ssiyer/r/superpages/(...)
Un document expliquant la problematique surement mieux que moi et une possible mise en oeuvre (pour FreeBSD).
[^]Re: Il manque
> Je pense au fait qu'aujourd'hui, sur certaine machines, le cache est trop gros pour avoir une complete couverture par la TLB (lire dans le document de mon second lien).
Au niveau hardware/cpu, je n'y connais pas grand chose :-)
Merci pour tes précisions.
[^]Re: Il manque
> 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.
[^]Re: Il manque
> > 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).
[^]Re: Il manque
> Cela donne 48bits d'adresse physique supportés (contre 39 avant si je ne m'abuse).
Ce n'est pas tout à fait ça si j'ai bien compris. Sur amd64 il y a deux espaces mémoires (parmis d'autres) :
- espace utilisateur
- espace physique
2^35 bits de page pour la mémoire virtuelle et 2^40 bits pour la mémoire physique selon les specs.
Avec page = 2^12.
Espace utilisateur est de 47 bits (128To). C'est les spec du cpu qui limite. Linux utilise tout.
Espace physique est de 52 bits (4096To) pour les spec. C'est 46 bits(64To) pour l'implémentation Linux. Les cpu actuels ne dépassent pas 40 bits (1To).
http://www.x86-64.org/lists/discuss/msg06059.html(...)
> Par contre la mémoire virtuelle des processus est limitée à 40bits (1To).
128To si j'ai bien compris.
mémoire virtuelle peut-être supérieur à mémoire physique car il y a le swap et mmap.
[^]Re: Il manque
> 2^35 bits de page pour la mémoire virtuelle et 2^40 bits pour la
> mémoire physique selon les specs.
>
> Avec page = 2^12.
> Espace utilisateur est de 47 bits (128To). C'est les spec du cpu
> qui limite. Linux utilise tout.
Ah oui en effet, c'est 47 et pas 48 bits d'adresse physique.
Voir dans include/asm-x86_64/pgtable.h :
et http://lwn.net/Articles/116954/(...)
Apparemment, les AMD64 supportent moins que sur les Opterons.
> > Par contre la mémoire virtuelle des processus est limitée à
> > 40bits (1To).
>
> 128To si j'ai bien compris.
> mémoire virtuelle peut-être supérieur à mémoire physique car il y a > le swap et mmap.
La mémoire virtuelle peut avoir une taille quelconque indépendante de la quantité de mémoire physique (128To ici puisque 47bits).
Le système peut limiter la mémoire virtuelle à la taille qu'il veut.
Linux a finalement choisit de limiter également à 47bits, en effet.
(cf TASK_SIZE dans include/asm-x86_64/processor.h)
[^]Re: Il manque
> Apparemment, les AMD64 supportent moins que sur les Opterons.
Je n'ai pas pensé qu'il puisse être différent sur ce point :-)
> Linux a finalement choisit de limiter également à 47bits, en effet.
> (cf TASK_SIZE dans include/asm-x86_64/processor.h)
Je n'y connais pas grand chose mais ce n'est pas ce que je vois.
Il me semble que c'est une limite du cpu qui se retrouve dans processor.h (voir pgtable.h que tu as pointé, 4 "indirections" de 9 bits (512 slots)). Ce qui est normal, Linux n'a pas à tenter d'accéder à un espace mémoire que le cpu ne peut de toute façon pas atteindre. N'oublions pas que page_size = 2^12. Si page_size > 2^12 on peut repousser cette limite.
Selon ce que je comprend, Linux "subit" le fait que le cpu ne peut utiliser que 2^35*page_size pour les adresses virtuelles. (D'accord, c'est 2^36 (2^(9*4)) mais je ne sais pas où j'ai perdu un bit :-)).
Là où Linux limite, c'est pour l'espace physique qui peut monter à 2^52 et Linux limite à 2^46 (pour des raisons que je n'ai pas compris). Mais ce n'est pas grave car actuellement le maximum disponible ("à l'achat") est 2^40.
[^]Re: Il manque
> D'accord, c'est 2^36 (2^(9*4)) mais je ne sais pas où j'ai perdu un bit :-)
Finalement j'ai compris. C'est 2^36*2^12 (2^48) pour tous l'asdressage mémoire mais il est divisé en deux :
- mémoire virtuel : 2^47
- mémoire noyau : 2^47
> Là où Linux limite, c'est pour l'espace physique qui peut monter à 2^52 et Linux limite à 2^46 (pour des raisons que je n'ai pas compris).
Non, Linux ne limite pas.
Puisque page_size fait 2^12, il y a 2^47 pour le mode noyau (comme pour la mémoire virtuelle) et dans ce 2^47 on garde la moitier (2^46) pour la mappage vers les adresses physiques.
Finalement, j'ai beaucoup appris :-)
Ce qui limite l'espace adressable par Linux, c'est le choix fait par Linux d'utiliser page_size=4096 comme pour x86 afin de pouvoir exécuter aussi des applis x86 (qui ont page_size=4096) et éviter d'inutile problème de compatibilité.
Mais augmenter page_size c'est aussi bouffer plus de mémoire.
Rien de dramatique dans le "page_size=4096" car on est déjà bien au delà des limites du hardware disponible. Pour un espace mémoire maxi avec amd64 et selon ses specs (mémoire physique limité à 2^52) il faudrait page_size=2^18 soit 256 ko (!). On aurait :
- mémoire virtuelle : 8192 To
- mémoire physique : 4096 To
Y a du gras.
[^]Re: Il manque
En effet, c'est un patch qui change pas mal quelques algorithmes.
N'empeche il serait temps que linux definisse une API de gestion de la VM qui se detache un peu des details de la MMU du x86. C'est pas pour dire, mais sur d'autres archi, la MMU ne travaille pas du tout avec des tables de traduction "directes" comme dans le cas x86 (je pense a ppc). Mieux vaudrait avoir une API bien plus propre, bien plus simple et bien plus portable que celle qui consiste a emuler les X niveaux d'indirection de la MMU x86.
Voila, c'etait mes 3 cents de mauvaise humeur... Troll en perspective ?
d2
[^]Re: Il manque
> detache un peu des details de la MMU du x86.
C'est le role du noyau d'être au plus près du hardware pour être le plus rapide possible.
Ce qu'il faut c'est que les drivers, applis soient portables. C'est le cas.
Dans un noyau il y a toujours des parties qui sont spécifiques au hardware.
[^]Re: Il manque
Ce que voulait surement dire D2 (ou plutôt D3, non ? ;) ), c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique, et permettant cependant d'utiliser des optimisations pour une implémentation d'une cible particulière.
La conception actuelle en 3 niveaux d'indirection fait référence au x86, alors que sur d'autres archi, on peut avoir 1 ou 2 niveau, voire un fonctionnement différent.
D'ailleurs, je ne sais pas comment ca se passe sur la MMU du PPC...
Linux a quand même été conçu initialement pour tourner sur un x86, mono-proc, etc, etc. Et ca se sent.... même dans la ligne 2.6 !
[^]Re: Il manque
> c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique
Oui mais c'est impossible.
> et permettant cependant d'utiliser des optimisations pour une implémentation d'une cible particulière.
Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.
> Linux a quand même été conçu initialement pour tourner sur un x86, mono-proc, etc, etc. Et ca se sent.... même dans la ligne 2.6 !
Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.
[^]Re: Il manque
(mais qui es-tu "borntoulouse" ? Tes initiales seraient-elles L.C. ? Ou R.J. ?)
Chouette, un troll pour techos !
>> c'est qu'un noyau qui se veut conçu pour être portable devrait être indépendant d'un quelconque modèle d'architecture réelle spécifique
Linux ne se voulait pas portable a ses debuts, c'est d'ailleurs sans doute pour ca qu'on a cette API foireuse au niveau de la gestion de la MMU.
> Oui mais c'est impossible.
Oh, allez, ne soyons pas defaitiste comme ça ! Allons, reprenons-nous ;)
> Optimization qui ne concerne qu'une partie du noyau. Les drivers ignorent cette optimisation dans la majorité des cas et ne vois que "bête" adresse.
Donc ca voudrait dire que les drivers devraient se contrefoutre de ces histoires de X niveaux d'indirection. Ce qui veut dire que si on a une API de gestion de la MMU qui ne rend pas publique ces histoires de X niveaux d'uindirections, alors les drivers ne se porteront pas plus mal. Bref, cette remarque va dans le sens de ce qui suit...
> Linux tient compte du réel. Si le cpu a besoin x niveaux pour l'exploité, Linux n'a d'autre choix que de les implémenter. Si tu ne les utilises pas (entre autre pour distinguer mémoire virtuelle et physique) autant retourner sous DOS.
Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc.. et bien sûr c'est cette couche qui s'occupe de fournir le necessaire a la MMU (tables de traduction directes, de hachage, etc...).
d2
[^]Re: Il manque
> c'est d'ailleurs sans doute pour ca qu'on a cette API foireuse au niveau de la gestion de la MMU.
De quoi tu parles ?
> Le CPU, ou plutot la MMU (qui est certes dans le CPU sur x86), a besoin de ces x niveaux, en effet. Par contre, "tu" ne les utilises pas directement. Justement, une API de la gestion de la MMU est une interface coincee entre la MMU et "tu" : c'est une couche d'abstraction intermediaire pour que "tu" n'aies pas a s'e**erder avec des histoires de niveaux d'indirection (x86), de tables de hachage (ppc), etc..
Donc tout va pour le mieux dans le meilleur des mondes.
Pour ton histoire d'API je ne vois pas de quoi tu parles. L'API pour accéder à la mémoire est une adresse mémoire. Ce n'est pas un "truc" avec des indirections etc.
[^]Re: Il manque
> Pour ton histoire d'API je ne vois pas de quoi tu parles. L'API pour
> accéder à la mémoire est une adresse mémoire. Ce n'est pas un
> "truc" avec des indirections etc.
Il parle du fait qu'actuellement, si tu veux traduire une adresse virtuelle, en adresse physique, tu dois parcourir la table des pages à la main. Les indirections dont il parle, ce sont les etapes du parcours des differents niveaux de la table de page.
Actuellement, si t'as une adresse "addr" d'un espace d'adressage "mm", tu dois faire (en virant les routines les verifications) :
pgd = pgd_offset(mm, addr);
pud = pud_offset(pgd, addr);
pmd = pmd_offset(pud, addr);
pte = pte_offset_map(pmd, addr);
page = pte_page(*pte);
pte_unmap(pte);
Et enfin tu as le cadre physique "page" où est mappée ton adresse virtuelle.
Cette API ne correspond à rien sur certaines architectures qui utilisent autre chose d'une table de page.
Il serait donc mieux d'avoir une API du genre:
page = mmu_translate(mm, addr);
Et que mmu_translate fasse le code ci-dessus sur ia32 et fasse un truc adapté à l'architecture sur les autres.
C'est ce qui a été proposé recemment.
Voir "A proposal for a major memory management rework" dans
http://lwn.net/Articles/124966(...)
[^]Re: Il manque
> Actuellement, si t'as une adresse "addr" d'un espace d'adressage "mm", tu dois faire (en virant les routines les verifications) :
> pgd = pgd_offset(mm, addr);
> ...
Qui doit faire/utiliser ça ?
Il n'y a que la partie du noyau qui gère la mémoire qui utilise ça (répertoire mm qui n'est pas lourd par rapport au reste).
C'est une API qui n'est pas exportée. C'est une API spécifique au hardware. Nul part (sauf répertoire mm) cette API est utilisée (sauf peut-être pour quelques cas d'optimisations).
Si tu fais un drivers, un fs, tout sauf ce qui n'est pas lié à la vm, tu ne touches jamais à ça.
Donc, tu ne parles pas d'API mais d'implémentation de la vm. C'est différent.
> Voir "A proposal for a major memory management rework" dans
http://lwn.net/Articles/124966(...)
Je n'y ai pas accès. Mais lis bien, c'est "A proposal for a major memory management rework". Ça ne conserne pas (mais je n'ai pas lu l'article) l'API qui est exporté.
[^]Re: Il manque
> Qui doit faire/utiliser ça ?
> Il n'y a que la partie du noyau qui gère la mémoire qui utilise ça
> (répertoire mm qui n'est pas lourd par rapport au reste).
Rien qu'en cherchant 3mn, j'ai le driver de ma webcam (spca50x) qui utilise ca, le DRM standard du noyau aussi, les drivers Myrinet, ...
Le noyau fournit aussi une API de plus haut niveau qui enrobe le parcours de page (par exemple pci_map_single). Et il ne faut pas oublier que le mapping linéaire permet de faire la translation rapidement avec virt_to_phys car on sait à l'avance ce que le parcours de la table de pages va donner.
Mais moralement, c'est la meme chose, les drivers veulent souvent traduire en adresses physiques.
Evidemment, ils utilisent la methode la plus simple.
Mais elle ne suffit pas toujours. Et dans ce cas, on utilise cette API.
> Donc, tu ne parles pas d'API mais d'implémentation de la vm. C'est
> différent.
Une API, c'est une "Application Programming Interface", ca veut dire interface logicielle de programmation. Ces fonctions sont exportées
dans les include/asm-/*.h de toutes les architectures.
Et un .h, c'est precisement un fichier où on ecrit les API.
> Je n'y ai pas accès. Mais lis bien, c'est "A proposal for a major
> memory management rework". Ça ne conserne pas (mais je n'ai
> pas lu l'article) l'API qui est exporté.
En effet, tu n'as pas lu l'article...
Par exemple :
"Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables; to that end, he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU)."
puis
"The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:"
Une "nouvelle couche d'abstraction" puis une "interface de remplacement proposée", c'est une nouvelle API.
[+] [^]Re: Il manque
> Une API, c'est une "Application Programming Interface", ca veut dire interface logicielle de programmation. Ces fonctions sont exportées
$ find * -not -path "Documentation/*" -not -path "arch/*" -not -path "include/*" -not -path "mm/*" -print0 | xargs -0 egrep -n "(pgd_offset)|(pud_offset)|(pmd_offset)|(pte_offset_map)|(pte_page)|(pte_unmap)"
drivers/char/drm/drm_memory.h:127: pgd_t *pgd = pgd_offset_k((unsigned long) vaddr);
drivers/char/drm/drm_memory.h:128: pmd_t *pmd = pmd_offset(pgd, (unsigned long) vaddr);
drivers/char/drm/drmP.h:155:#ifndef pte_offset_map
drivers/char/drm/drmP.h:156:#define pte_offset_map pte_offset
drivers/char/drm/drmP.h:157:#define pte_unmap(pte)
drivers/char/drm/drmP.h:165: pgd_t *pgd = pgd_offset_k(addr);
drivers/char/drm/drmP.h:170: pmd = pmd_offset(pgd, addr);
drivers/char/drm/drmP.h:173: ptep = pte_offset_map(pmd, addr);
drivers/char/drm/drmP.h:176: page = pte_page(pte);
drivers/char/drm/drmP.h:177: pte_unmap(ptep);
fs/exec.c:313: pgd = pgd_offset(mm, address);
fs/exec.c:323: pte_unmap(pte);
fs/exec.c:331: pte_unmap(pte);
Voilà, c'est tout.
Impressionnant l'utilisation de l'API...
> Ces fonctions sont exportées dans les include/asm-/*.h de toutes les architectures.
Et les ficheirs dans include/asm sont spécifiques aux architectures !
Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure et qu'en gros tu n'as pas le choix !
> Christoph Lameter would like to get rid of the disconnect between in-kernel and hardware page tables
Et alors ? Qui te dis que ça impacte l'API (or arch et include/asm car c'est SPÉCIFIQUE au hardware).
> Une "nouvelle couche d'abstraction" puis une "interface de remplacement proposée", c'est une nouvelle API.
Une API pour qui ?
Pour "mm/" seulement ?
[^]Re: Il manque
> Et les ficheirs dans include/asm sont spécifiques aux architectures
> Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure
> et qu'en gros tu n'as pas le choix !
Un contre-exemple parmi des centaines :
Copier des données entre espace user et noyau est une chose très courante et que n'importe quel driver non-architecture-spécifique peut vouloir faire (relance ton find pour t'en rendre compte). Mais l'implémentation de copy_from_user est très architecture spécifique et exportée uniquement dans les asm/uaccess.h.
Les fichiers asm/*.h du noyau sont justement là pour masquer les choses dépendantes de l'architecture et fournir une interface uniforme.
Il est tout a fait normal pour n'importe qui d'inclure un fichier asm/*.h même pour programmer un truc pas du tout architecture spécifique.
> > Christoph Lameter would like to get rid of the disconnect
> > between in-kernel and hardware page tables
>
> Et alors ? Qui te dis que ça impacte l'API (or arch et include/asm
> car c'est SPÉCIFIQUE au hardware).
C'est facile de dire ca après avoir viré les parties intéressantes du texte que j'avais cité. Il dit explicitement qu'il veut créer une nouvelle couche d'abstraction des MMU et une interface de remplacement, c'est-à-dire une API :
"he has proposed a new abstraction layer which would handle access to the processor's memory management unit (MMU)."
"The proposed replacement interface is somewhat vague at this stage, but some features have been sketched out:"
(Je réinsère la citation pour voir si tu vas encore la virer).
Visiblement tu as très peu de connaissance du noyau et de sa programmation donc je vais te laisser continuer à troller tout seul
car je vous bien que je perds mon temps à essayer de t'expliquer les choses de la vie.
[+] [^]Re: Il manque
> > Et les ficheirs dans include/asm sont spécifiques aux architectures
> > Ils n'ont à être utilisé que si tu fais un truc SPÉCIFIQUE à l'architure
> > et qu'en gros tu n'as pas le choix !
J'ai écrit une connerie car t'as écrit une connerie :
- Ces fonctions sont exportées dans les include/asm-/*.h de toutes les architectures.
Je voulais dire "include/asm-*".
Pour priciser :
include/asm : API indépendante de l'architecture
include/asm-* : API dépendante de l'architecture
Que asm soit un lien sur asm-* ne change rien.
Lorsque tu fais "include <asm/*.h>" tu signifies : j'ai besoin de l'API générique (portable (indépendante du hardware)).
Lorsque tu fait "include <asm-*/*.h>" tu signifies : j'ai besoin de l'API spécifique à un hardware. Donc normalement "include/asm-*" n'est pas utilisé hors "arch/*".
> Visiblement tu as très peu de connaissance du noyau et de sa programmation
Connard.
[^]Re: Il manque
> J'ai écrit une connerie car t'as écrit une connerie :
> - Ces fonctions sont exportées dans les include/asm-/*.h de
> toutes les architectures.
N'essaie pas de te cacher derrière des caractères manquant ou en trop. Ma phrase reste parfaitement vraie que ce soit asm ou asm-*.
grep est là pour le prouver.
Les gens qui incluent pgtable.h pour utiliser pgd_offset and co, ils incluent bien asm/pgtable.h et pas asm-*/pgtable.h.
C'est le cas dans drm et dans fs que tu avais cités avec ton find, et également dans le driver de ma webcam et le driver Myrinet.
> Lorsque tu fais "include <asm/*.h>" tu signifies : j'ai besoin de l'API
> générique (portable (indépendante du hardware)).
> Lorsque tu fait "include <asm-*/*.h>" tu signifies : j'ai besoin de l'API
> spécifique à un hardware. Donc normalement "include/asm-*" n'est
> pas utilisé hors "arch/*".
Exactement, c'est ce qui permet de conclure que l'API pgd_offset and co. est bien independante de l'architecture.
CQFD.
[^]Re: Il manque
> Exactement, c'est ce qui permet de conclure que l'API pgd_offset and co. est bien independante de l'architecture.
Et comme indiqué plus haut, ce n'est pas ou peu utilisé. C'est utilisé que s'il n'y a pas le choix. L'architecture ou certain driver l'impose mais pas Linux. Linux doit faire avec ce que lui fournit le hardware.
[^]Re: Il manque
fabb, dans un noyau il n'y a pas qu'1 API destinee aux drivers. Il y en a pour tous les sous-systemes, qui sont eux-memes utilises par les autres sous-systemes, utilises par les autres sous-systemes, etc... utilises par les drivers, utilises par d'autres sous-systemes, etc... utilises par les applications utilisateur.
Bref, une API noyau n'est pas forcement utilisee par les drivers directement. C'est pas pour ca qu'on doit dire "boarf, c'est de la cuisine interne au noyau, c'est forcement bas niveau, donc ca depend du matos et le noyau se debrouille.". Non. Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise. Parce qu'une contrainte des noyaux du genre Linux, c'est qu'il doit etre "portable", ie adaptable a plusieurs archi en touchant le moins de code possible. Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi. Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?
Bon, j'espere que jusqu'ici c'est clair. Maintenant qu'on a dit qu'une API de gestion de la MMU etait necessaire (bien que peu de drivers l'utilisent directement), la question se pose de la definir. Dans Linux, l'histoire a choisi une API a base de tables simples avec 2 ou 3 indirections (resp 3 ou 4 niveaux de tables). Eh bien je ne suis pas convaincu que ce soit le meilleur choix. D'une part parce que cette API est un gouffre en termes de perf quand l'archi ne repose pas sur un systeme a indirection simple parce que emuler en soft ce systeme peut etre tres complexe quand on ne dispose pas en hard des elements en question (ex : ppc repose sur une serie de tables de hachage, pas facile d'emuler des tables a indirection a partir de ca). D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.
Pour Brice : vivement Jeudi que je lise cet article lwn ! Si ca continue je m'abonne.
d2
[^]Re: Il manque
> Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise.
Je suis parfaitement d'accord. Mais lorsqu'on parle API il faut être précis. Si on me parle d'API de la vmm sans plus de précision, je pense à l'API utilisable par un module externe et pas au sein du système de gestion de la vmm.
Si je dis que l'API de libxml2 est bien faite, tout le monde comprend que je parle de l'API "externe" et pas de la tembouille interne.
> Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi.
Pas totalement d'accord. Dans l'idéal, ça doit être le même code. Ce qui compte avant tout c'est que l'interface, l'API "externe", soit la même pour tout le monde.
De tout manière, il est *impossible* d'avoir le même code pour toute les architectures, ou plus précisément il y a toujours un moment ou tu dois prendre en compte les spécificité de l'architecture pour des raisons de performance. C'est bien le role du noyau (ou de tout module réutilisable) de prendre en compte les spécificités et de les masquer. Mais au final il faudra *toujours* du code spécifique.
> Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?
Tu peux toujours repousser l'encapsulation. Savoir où et jusqu'où il faut le faire n'est en rien évident (surtout pour un noyau ou le critère performance est très important).
Tu peux faire un noyau en java, mais c'est lent et le code spécifique que tu as retiré en utilisant java, tu le retrouves dans java. Le gain est nul.
> D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.
L'interface (externe) se passe de ce genre de détail (sauf pour quelques cas rarement utilisé). Donc la voie est libre pour implémenter différement la VMM où même faire une VMM totalement spécifique à ppc sans retoucher (ou peu) l'API externe.
Au final et pour être bien d'accord. Je ne vais pas dire les avantages ou inconvénient des techniques de telle ou telle vmm. Je n'ai pas les compétences. Ce qui m'"énerve" c'est de voir les gens parler d'_API_ en des définissants comme spécifiques à une architecture.
Ce que tu reproches à la vmm ici (et si j'ai bien compris) a du sens. Tu ne reproches pas l'API (externe) mais que la vmm "colle" que système qu'on retrouve sur les systèmes types x86 et que ce n'est pas forcement la bonne aproche pour toutes les architectures. Tu ne demandes pas que l'API (externe) soit encore plus neutre par rapport au architecture mais que son fonctionnement interne soit plus neutre et pas "optimisé" pour un type d'architecture.
Je n'ai pas de problème avec ça.
[^]Re: Il manque
> vivement Jeudi que je lise cet article lwn !
Tu peux aussi aller lire directement l'annonce sur la LKML :
http://marc.theaimsgroup.com/?l=linux-ia64&m=110922543030922&w=2