Articles précédents : Code
- [29] Délégation de pouvoirs avec un contrôleur de domaine Samba
- [96] Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4
- [107] SPT : Une alternative au système historique de partitionnement des PC
- [40] Sortie de OpenBGPd
- [60] « Autocompiler » son noyau au démarrage avec TCCBoot
- [11] Busybox 1.0
- [101] John Carmack victime des brevets logiciels
- [154] Le code de Java3D est disponible
- [26] GFS à nouveau en GPL et résultats financiers de Red Hat
- [79] Linux VServer, pour ceux qui ne connaissent pas...
Liens connexes
- Le noyau linux (1830 hits)
- InfiniBand (742 hits)
- L'email d'annonce (762 hits)
- 2.6.11 sur kernaltrap (1289 hits)
- ChangeLog (994 hits)
Dépêche modérée par
Dépêche éditée par
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 (1830 hits)-
InfiniBand (742 hits)
-
L'email d'annonce (762 hits)
-
2.6.11 sur kernaltrap (1289 hits)
-
ChangeLog (994 hits)
> Lire la dépêche (92 commentaires, moyenne: 2,6).
whaouh! j ai hate d essayer çà !!
Ce soir c'est soirée compilation!!
avec mon ibm t42, lire cette phrase :
"Ce noyau apporte une grande liste de mises à jour : pilotes ACPI, [..]"
c'est que du bonheur, non pas que l'ACPI ne focntionnait pas jusqu'à présent, non, juste que peut être le déréglage de l'horloge et l usb qui saute en retour de suspend auront peut etre disparus...
allez, bon "make menuconfig" à tous !
Rendez vous sur http://dahanne.net
-
[^]Re: whaouh! j ai hate d essayer çà !!
Posté par Stephane () le 02/03/2005 à 16:07. (lien). Évalué à 4.tout pareil avec le x31 (devenue une excroissance permanente de mon anatomie ;-)
je suis un peu las de devoir décharger tous les modules usb avant de partir en suspend ou en hibernation (sans assurance d'ailleurs que ça refonctionnera au resume).
/me's going to pray...-
[^]testé ok sur un laptop AmiloA
Posté par rzr (page perso, ) le 02/03/2005 à 21:42. (lien). Évalué à 5.j'ai pas encore testé le swsuspend, mais j'ai trouvé une regression ?
le "double tap" ne marche plus comme click gauche, mais y a un param de boot peut etre : mousedev.tap_time
sinon des patchsets sympatoches a l'horizon pour le 2.6.11 ?
A suivre...-
[^]Re: testé ok sur un laptop AmiloA
Posté par asbin (page perso, ) le 03/03/2005 à 11:20. (lien). Évalué à 2."sinon des patchsets sympatoches a l'horizon pour le 2.6.11 ?"
Moi je patch toujours mon kernel avec le cko (Con Kolivas patchset based overloaded kernel), voir ici : http://kem.p.lodz.pl/~peter/cko/(...)
C'est une suite sympathique, avec des mises à jour de alsa, acpi, bttv, avec fbsplash et vesafb-ng, avec le Software Suspend 2, reiser4 et supermount, ainsi que les patchs d'Alan Cox (les -ac) ... bref, que du bonheur !
;-]
-
-
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
Posté par fabb () le 02/03/2005 à 16:33. (lien). Évalué à 10.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
Posté par mdlh () le 02/03/2005 à 21:16. (lien). Évalué à 4.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
Posté par fabb () le 03/03/2005 à 01:00. (lien). Évalué à 0.> 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
Posté par mdlh () le 03/03/2005 à 01:12. (lien). Évalué à 3.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
Posté par fabb () le 03/03/2005 à 02:58. (lien). Évalué à 2.> 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
Posté par galactikboulay () le 03/03/2005 à 08:27. (lien). Évalué à 2.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
Posté par Christophe Fergeau () le 03/03/2005 à 09:21. (lien). Évalué à 2.> 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
Posté par galactikboulay () le 03/03/2005 à 09:34. (lien). Évalué à 1.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
Posté par Christophe Lucas (page perso, ) le 03/03/2005 à 09:48. (lien). Évalué à 1.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
Posté par galactikboulay () le 03/03/2005 à 10:39. (lien). Évalué à -1.Bonjour, dans la série "j'apprends à lire":
"le processeur utilise un cache TLB"-
[^]Re: Il manque
Posté par Christophe Lucas (page perso, ) le 03/03/2005 à 11:29. (lien). Évalué à 3.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
Posté par reno () le 03/03/2005 à 18:59. (lien). Évalué à 1.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
Posté par zeSixty4Douille () le 03/03/2005 à 13:15. (lien). Évalué à -5.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
Posté par mdlh () le 03/03/2005 à 14:40. (lien). Évalué à 6.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
Posté par fabb () le 03/03/2005 à 18:04. (lien). Évalué à 1.> 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
Posté par Brice Goglin () le 05/03/2005 à 01:23. (lien). Évalué à 4.> 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
Posté par Brice Goglin () le 05/03/2005 à 00:25. (lien). Évalué à 4.> > 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
Posté par fabb () le 05/03/2005 à 12:19. (lien). Évalué à 2.> 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
Posté par Brice Goglin () le 05/03/2005 à 12:55. (lien). Évalué à 1.> 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
Posté par fabb () le 05/03/2005 à 14:26. (lien). Évalué à 1.> 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
Posté par fabb () le 05/03/2005 à 15:01. (lien). Évalué à 1.> 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
Posté par David Decotigny (page perso, ) le 03/03/2005 à 09:24. (lien). Évalué à 7.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
Posté par fabb () le 03/03/2005 à 18:13. (lien). Évalué à 1.> 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
Posté par borntoulouse () le 04/03/2005 à 19:06. (lien). Évalué à 1.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
Posté par fabb () le 05/03/2005 à 12:27. (lien). Évalué à 1.> 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
Posté par David Decotigny (page perso, ) le 06/03/2005 à 16:35. (lien). Évalué à 2.(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
Posté par fabb () le 06/03/2005 à 17:30. (lien). Évalué à 0.> 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
Posté par Brice Goglin () le 06/03/2005 à 17:45. (lien). Évalué à 3.> 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
Posté par fabb () le 06/03/2005 à 19:32. (lien). Évalué à 0.> 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
Posté par Brice Goglin () le 06/03/2005 à 19:51. (lien). Évalué à 4.> 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
Posté par fabb () le 06/03/2005 à 23:06. (lien). Évalué à -2.> 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
Posté par Brice Goglin () le 06/03/2005 à 23:34. (lien). Évalué à 2.> 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
Posté par fabb () le 07/03/2005 à 01:27. (lien). Évalué à -3.> > 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
Posté par Brice Goglin () le 07/03/2005 à 08:14. (lien). Évalué à 3.> 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
Posté par fabb () le 07/03/2005 à 23:49. (lien). Évalué à 1.> 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
Posté par David Decotigny (page perso, ) le 07/03/2005 à 22:50. (lien). Évalué à 2.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
Posté par fabb () le 07/03/2005 à 23:45. (lien). Évalué à 1.> 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
Posté par Brice Goglin () le 07/03/2005 à 23:52. (lien). Évalué à 2.> 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
-
-
-
-
-
-
-
-
-
-
-
-
-
Ahh
Salut,
et xen c'est pour quand ?
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/(...)
J'ai lu quelque part que c'etait pour le 2.6.12, quelqu'un confirme ?
ici :
http://www.crn.com/sections/breakingnews/breakingnews.jhtml?article(...)
Merci
InfiniBand...
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.
Il me semble que cette définition est inexacte (cf http://www.oreillynet.com/pub/a/network/2002/02/04/windows.html(...) )
L'infiniband, c'est plutôt une technologie d'interconnection caractérisée par une faible latence et un gros débit, et est plutôt présenté comme un remplaçant d'ethernet ou mirinet pour les calculs sur grid.
Bon, si on regarde sur le wikipedia: http://en.wikipedia.org/wiki/InfiniBand(...) il semble bien qu'Infiniband se veut comme un remplaçant d'autant ethernet que le bus PCI...
Tout ça pour dire que jusqu'à présent, on pouvait difficilement avoir des gros débits de noeuds à noeuds en réseau local avec des technologies courantes, mais que heureusement est arrivé Infiniband!
-
[^]Re: InfiniBand...
Posté par Maxime Ritter (page perso, ) le 02/03/2005 à 21:56. (lien). Évalué à 6.Je confirme Infiniband est d'une certaine manière le successeur de myrinet ou de Dolphin SCI, en ce qui concerne les cartes réseau faible latence et fort débit utilisés dans les clusters Hautes Performances (HPC). Infiniband, en plus d'être plus performant a également l'avantage d'être un standard, donc on n'est plus cantonné à un seul fournisseur.
Par contre, rien à voir avec les calculs sur grid. Dans les grids, la vitesse de communication entre les noeuds est extremment aléatoire, ils ne sont pas concus pour faire tourner des programmes ayant de gros besoin de communication entre eux. Pas de MPI sur les grids en général, alors qu'au contraire avec Infiniband, on n'utilisera à 90% des programmes basés sur MPI (ou son ancêtre PVM).-
[^]Re: InfiniBand...
Posté par Brice Goglin () le 05/03/2005 à 01:32. (lien). Évalué à 4.> 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à.
-
InfiniBand, c'est un réseau pour grappes
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.
Imodules proprio NVIDIA
Il semblerait que les modules proprio NVIDIA ne fonctionne plus avec ce nouveau kernel. Aprés quelques recherches, j'ai trouvé ça, mais n'ai pas encore eu le temps de tester
http://unixforge.org/~matthias-christian-ott/index.php?entry=entry0(...)
"On obtient plus de chose en étant poli et armé qu'en étant juste poli" Al Capone
-
[^]Re: Imodules proprio NVIDIA
Posté par dromadaire35 () le 02/03/2005 à 18:34. (lien). Évalué à 6.Pour ce qui est du driver proprio nvidia, la recette et le patch qu iva bien pour le faire tourner sur un beau noyau 2.6.11 sont là :
http://www.nvnews.net/vbulletin/showthread.php?t=46676(...)
-
[^]Re: modules proprio NVIDIA
Posté par Amand Tihon (page perso, ) le 02/03/2005 à 22:27. (lien). Évalué à 7.Le paquet debian des drivers doit avoir l'un ou l'autre patch alors, parce que chez moi, c'est passé comme un pet sur une toile cirée (ou comme une fleur, pour les plus poétiques)
-
[^]Re: modules proprio NVIDIA
Posté par mansuetus (page perso, ) le 03/03/2005 à 11:41. (lien). Évalué à 3.Ma petite aventure NVidia...
j'ai installé le 2.6.11 en croisant les doigts, make && make install && make modules_install
ça boot !
j'installe le driver NVIDIA, startx, et poof, ça marche !
là, je lance ma carte TV, ça freeze (comme d'hab) et je reboot (reset button), et là, plein de UNEXPECTED SYMBOL au moment du chargement NVidia.
solution : ré-installer le driver à chaque reboot, en attendant le patch :/
(rude, but woks)
Mes2cents-
[^]Re: modules proprio NVIDIA
Posté par Alexandre () le 05/03/2005 à 10:54. (lien). Évalué à 2.Quelqu'un pourrait m'expliquer ce que signifie l'histoire des "2cents" qui reviennent si souvent sur DLFP ?
--
Un serveur sûr est une machine éteinte enfermée dans un coffre, et encore...-
[^]Re: modules proprio NVIDIA
Posté par lapougnou () le 05/03/2005 à 11:32. (lien). Évalué à 6.C'est la traduction mot à mot de l'expression "my two cents". Je le traduirais plutôt par "ma modeste contribution", "mon humble avis" ou encore "ma réflexion à deux balles" si on veut garder le côté monétaire de l'expression originale.
Le fait de dire cents au lieu de centimes doit être pour faire plus djeuns...-
[^]Re: modules proprio NVIDIA
-
[^]Re: modules proprio NVIDIA
Posté par nigaiden () le 07/03/2005 à 08:20. (lien). Évalué à 2.>Le fait de dire cents au lieu de centimes doit être pour faire plus djeuns...
Sur les pièces françaises, il est bien marqué "cent" et non pas "centime". Ce qui me choque le plus, c'est que sur ces mêmes pièces, le nom n'est pas accordé ; ainsi on a "10 euro cent" alors que j'aurais plutôt mis "10 euro cents".
-
-
-
-
2.6.12
Intérressant, sur KernelTrap, un aperçu de quelques unes des nouveautés prévues pour le 2.6.12, dont en particulier :
- FUSE (système de fichiers en user space, à la LUFS et compagnie)
- cpusets: un système de partitionnement des resources CPU des machines SMP (en gros si je comprends bien, à la fois de la virtualisation et de l'allocation explicite des ressources CPU à certaines tâches)
Et puis plein d'autres choses, dont rien de garanti bien sûr.
http://kerneltrap.org/node/4789(...)
-
[^]Re: 2.6.12
Posté par udok () le 03/03/2005 à 10:54. (lien). Évalué à 2.ça promet FUSE, avec ça les devels ouvrent les portes vers tout un tas d'extensions très intéressantes et pourquoi pas se rapprocher du fonctionnement des translators sous hurd ... c'est dommage, ça enlève encore un intéret à ce dernier, va pu lui rester grand chose :-/
-
[^]Re: 2.6.12
Posté par gnumdk () le 03/03/2005 à 21:57. (lien). Évalué à 4.Dire que FUSE c'est du user space, c'est quand meme un demi gros mensonge, ca reste quelque chose qui tourne en kernel space pour la présentation(l'intégration?) dans le fs linux, donc bon, le hurd propose quelque chose de mieux ;)
-
[^]Re: 2.6.12
-
[^]Re: 2.6.12
Posté par fabb () le 04/03/2005 à 01:24. (lien). Évalué à 1.Pour le fun, une partie de la partie user space d'un fs rpm :
#! /bin/sh
...
mcrpmfs_list ()
{
# set MCFASTRPM_DFLT to 1 for faster rpm files handling by default, to 0 for
# slower handling
MCFASTRPM_DFLT=0
if test -z "$MCFASTRPM"; then
MCFASTRPM=$MCFASTRPM_DFLT
fi
FILEPREF="-r--r--r-- 1 root root "
DESC=`rpm -qip "$1"`
DATE=`rpm -qp --qf "%{BUILDTIME:date}\n" "$1" | cut -c 5-11,21-24`
HEADERSIZE=`echo "$DESC" | wc -c`
echo "-r--r--r-- 1 root root $HEADERSIZE $DATE HEADER"
echo "-r-xr-xr-x 1 root root 39 $DATE INSTALL"
echo "-r-xr-xr-x 1 root root 39 $DATE UPGRADE"
echo "dr-xr-xr-x 3 root root 0 $DATE INFO"
echo "$FILEPREF 0 $DATE INFO/NAME-VERSION-RELEASE"
echo "$FILEPREF 0 $DATE INFO/GROUP"
...
mcrpmfs_copyout ()
{
case "$2" in
HEADER) rpm -qip "$1" > "$3"; exit 0;;
INSTALL) echo "# Run this to install this RPM package" > "$3"; exit 0;;
UPGRADE) echo "# Run this to upgrade this RPM package" > "$3"; exit 0;;
INFO/NAME-VERSION-RELEASE) rpm -qp --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" "$1" > "$3"; exit 0;;
INFO/RELEASE) rpm -qp --qf "%{RELEASE}\n" "$1" > "$3"; exit 0;;
INFO/GROUP) rpm -qp --qf "%{GROUP}\n" "$1" > "$3"; exit 0;;
...
-
-
Macs
Et les laptops Apple G4 dotés d'une ATI, comme les iBooks G4 ou certains AlBooks, sont enfin capables de se mettre en veille! (merci BenH, comme d'hab)
-
[^]Re: Macs
Posté par Michel Pastor () le 04/03/2005 à 00:15. (lien). Évalué à 1.Ça c'est vraiment une bonne nouvelle, je l'attendais depuis longtemps.
Félicitation a BenH qui fait vraiment du très bon boulot.
Il ne manque plus que le support du chipset Airport Broadcom pour finaliser le support des portables Apple car il faut dire que c'est quand même un gros handicap pour linux sur Mac (surement pas pour tout le monde mais pour moi ça en est un gros).
2.6.11 sur laptop ASUS W1N
Testé et approuvé...le support d'ALSA permet maintenant d'avoir du son et le réglage du volume via artsd sur le laptop ASUS W1N sans avoir à forcer les valeurs pour les registres d'alsa.
Le son fonctionnait mais les HP n'étaient pas activés.
Sur les noyaux précédents il fallait compiler avec les options de debug pour ALSA et forcer à la main les valeurs suivantes pour les registres :
echo -n "26 000F" > /proc/asound/card0/codec97#0/ac97#0-0+regs
echo -n "36 0000" > /proc/asound/card0/codec97#0/ac97#0-0+regs
echo -n "64 7110" > /proc/asound/card0/codec97#0/ac97#0-0+regs
-
[^]Re: 2.6.11 sur laptop ASUS W1N
Posté par jaune (page perso, ) le 05/03/2005 à 21:02. (lien). Évalué à 3.Et à propos d'alsa, les cartes son SBLive à base de chip emu10k1 bidouillées par dell fonctionnent désormais sous Linux.
Version de développement
D'après les dernières discussions sur la lkml dans le thread "Kernel release numbering" de Linus, il s'agirait d'une version de développement. Ou du moins, les futures versions impaires 2.6.x seraient des versions de développement.
http://lkml.org/lkml/2005/3/2/247(...)
-
[+] [^]Re: Version de développement
Posté par eddine () le 04/03/2005 à 11:04. (lien). Évalué à -1.Je comprends pas pourquoi ce comm a été "moinsé"...
-
[^]Re: Version de développement
Posté par FReEDoM (page perso, ) le 04/03/2005 à 13:30. (lien). Évalué à 4.
In other words, we'd have an increasing level of instability with an odd
release number, depending on how long-term the instability is.
- 2.6.: even at all levels, aim for having had minimally intrusive
patches leading up to it (timeframe: a week or two)
with the odd numbers going like:
- 2.6.: still a stable kernel, but accept bigger changes leading up
to it (timeframe: a month or two).
- 2..x: aim for big changes that may destabilize the kernel for
several releases (timeframe: a year or two)
- .x.x: Linus went crazy, broke absolutely _everything_, and rewrote
the kernel to be a microkernel using a special message-passing version
of Visual Basic. (timeframe: "we expect that he will be released from
the mental institution in a decade or two").
he he :)-
[^]oops pardon
Posté par FReEDoM (page perso, ) le 04/03/2005 à 13:52. (lien). Évalué à 2.
In other words, we'd have an increasing level of instability with an odd
release number, depending on how long-term the instability is.
- 2.6.< even >: even at all levels, aim for having had minimally intrusive
patches leading up to it (timeframe: a week or two)
with the odd numbers going like:
- 2.6.< odd >: still a stable kernel, but accept bigger changes leading up
to it (timeframe: a month or two).
- 2.< odd >.x: aim for big changes that may destabilize the kernel for
several releases (timeframe: a year or two)
- < odd >.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
the kernel to be a microkernel using a special message-passing version
of Visual Basic. (timeframe: "we expect that he will be released from
the mental institution in a decade or two").
-
[^]Re: oops pardon
Posté par herodiade () le 04/03/2005 à 17:50. (lien). Évalué à 4.Tu devrai lire tout le thread:
From: Linus Torvalds <torvalds () osdl ! org>
"[...]I think we should drop the
original even/odd suggestion for now, and see if this would make more
sense.."
http://marc.theaimsgroup.com/?l=linux-kernel&m=110987495523158&(...)-
[^]Re: oops pardon
Posté par Brice Goglin () le 05/03/2005 à 00:17. (lien). Évalué à 1.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.
-
-
-
-
No medium found
Malgré d'innombrables tentatives de me sortir de cette galère, mes lecteurs multi-cartes (Xdrive II et lecteur simple) auxquels je confie ma SD, me renvoient toujours ce message : "No medium found".
Les rescan-scsi.sh, echos 1 > /sys/.../rescan, le paramétrage de udev pour pré-allouer les pilotes, n'ont aucun effet. J'ai testé tout ce que Google me trouvait.
Tout est là, dans /dev, la log indique que tout est reconnu...
Ça marchait à une époque (sur un 2.4 c'est sûr, mais y'a pas udev - qui m'a incité à passer au 2.6), mais ça ne marche plus. Je nourrissais quelque espoir pour ce nouvo noyo, en vain.
Devrai-je faire une recherche dichotomique pour retrouver un kernel qui marche (pas glop), ou bien quelqu'un aurait-il une solution miraculaire ?
AU SECOURS :-)
-
[^]Re: No medium found
Posté par ebdomino (page perso, ) le 05/03/2005 à 16:05. (lien). Évalué à 2.salut t'as essayé :
http://ebdomino.free.fr/lecteur_multi_cartes.html(...)
??
tiens moi au courant-
[^]Re: No medium found
Posté par Lorenzo () le 05/03/2005 à 17:43. (lien). Évalué à 2.Merci pour le lien, mais ça ne marche pas. Pourtant j'suis pas un imbécile, puisque je suis doua^Winformaticien :-)
J'ai viré mes "renommages" udev, on ne sait jamais.
J'avais bien "Probe all LUNs..." activé (et j'avais lu que ça dispensait du paramètre "max_scsi_luns", mais j'ai testé quand même).
Ce qui est frustrant, c'est qu'il reconnait tous les lecteurs (SMC, CFC, MMC, MSC), il dit qu'il les attache à sd[a..d], et effectivement, je les retrouve dans /dev.
(D'ailleurs j'ai le même résultat que je branche d'abord le lecteur puis que j'y glisse la SD ou que je branche le lecteur avec la SD déjà connectée.)
Mais le mount est toujours aussi agaçant...
Le seul truc qui semble rester, c'est les pilotes USB compilés dans le noyo plutôt qu'en modules. Au fait, je n'ai activé le support d'aucun lecteur en particulier (sous "USB Mass Storage support") puisqu'il *semble* être reconnu.
Bord... c'est le premier truc qui me résiste autant sous Linux, grrr-
[^]Re: No medium found
Posté par ebdomino (page perso, ) le 08/03/2005 à 16:44. (lien). Évalué à 1.j'ai répondu à ton pv, :-) essaies de compiler l'usb en externe et le module usb-mass-storage aussi, si tu veux une bonne conf la dessus regardes la:
http://people.via.ecp.fr/~alexis/formation-linux/config/config-2.6.(...)
j'utilises cette conf comme base.
a+
-
-
Oui, mais ...
... j'aurais déjà aimé profité des 2.6.9 et 2.6.10 sous debian ...
Alors le 2.6.11 ! :)
/!\ débranchez vos trollomètres, je confirme que c'en était un ! :)
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.
-
[^]Re: Oui, mais ...
Posté par Brice Goglin () le 05/03/2005 à 10:38. (lien). Évalué à 3.> ... 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.
-
[^]Re: Oui, mais ...
Posté par tchibitchi () le 05/03/2005 à 18:09. (lien). Évalué à 1.Il est vraiment si difficile d'aller telecharger les sources toi-meme sur kernel.org ?
Non, car je suis déjà sous un 2.6.11.
Cependant, j'ai beau faire un coup de
root@brouettej ~ #>apt-cache search 2.6.1| grep -i kernel
kernel-patch-2.6-bluez - Linux Bluetooth protocol stack kernel patches
kernel-patch-lkcd - linux Kernel Crash Dump - kernel patch
Pas de kernel-source, ni de header, ni de binaire, etc...
Perso, je préfère compiler les sources du noyaux patchées par Debian.
Bon, cela dit, make bzImage, make modules, make modules_install, mkinitrd -o /boot/initrd-2.6.11N 2.6.11N, ça n'est effectivement pas très difficile ! :)-
[^]Re: Oui, mais ...
Posté par Sylvain Sauvage () le 05/03/2005 à 18:16. (lien). Évalué à 2.make-kpkg --initrd kernel-image !
(Ça fonctionne aussi très bien avec des noyaux de kernel.org !)
-
[^]Re: Oui, mais ...
Posté par Brice Goglin () le 05/03/2005 à 18:43. (lien). Évalué à 2.> Pas de kernel-source, ni de header, ni de binaire, etc...
> Perso, je préfère compiler les sources du noyaux patchées par
> Debian.
Le noyau 2.6.10 précompilé est dans sid, pas dans sarge (dont le noyau standard est 2.6.8). C'est pareil pour les sources.
kernel-source-2.6.10 est dispo dans sid.
kernel-headers n'a plus vraiment d'utilité depuis 2.6 car (contrairement à 2.4), il faut beaucoup plus que quelques fichiers.h pour pouvoir compiler un module externe.
Ceci dit, je suis d'accord, Debian n'est vraiment pratique pour recuperer facilement les sources de leurs noyaux precompilés
(ou le patch associé). C'est vraiment fatiguant quand on veut compiler un module externe.
Par contre, comme Debian applique très peu de patchs (contrairement à Redhat ou Mandrake), partir d'un noyau Vanilla est finalement pas très différent. Si vraiment on veut un noyau proche de Debian, on peut appliquer eventuellement le patch -as qui est justement géré par le mainteneur Debian et sert de base au noyaux précompilés.
> Bon, cela dit, make bzImage, make modules, make modules_install,
> mkinitrd -o /boot/initrd-2.6.11N 2.6.11N, ça n'est effectivement pas
> très difficile ! :)
Surtout que depuis 2.6, il suffit de faire "make" au lieu de "make bzImage" et "make modules" comme précedemment...-
[^]Re: Oui, mais ...
Posté par tchibitchi () le 06/03/2005 à 11:15. (lien). Évalué à 1.kernel-source-2.6.10 est dispo dans sid
Sans vouloir dire que j'ai une machine de production chez moi, je ne me limite qu'aux paquets de la testing. C'est que, si je peux supporter que certaines fonctionnalités soient déficientes par ma faute, il n'en est pas forcément de même pour les autres utilisateurs ;)
kernel-headers n'a plus vraiment d'utilité depuis 2.6 car (contrairement à 2.4), il faut beaucoup plus que quelques fichiers.h pour pouvoir compiler un module externe.
Damned ! Je n'avais pas l'info. Donc, je m'embête pour rien quand j'installe les kernel-headers du 2.6.8 ? Dépaqueter les sources, ça suffit ?
Une feature qui m'avait bloquée pour compiler moi-même mes noyaux, dernièrement, c'est qu'à l'install du noyau compilé via make-kpkg, mkinitrd rate parce-qu'il cherche les modules dans /lib/modules/<nom_correct>N
Je ne sais pas d'où sort ce "N", mais le noyau ne s'installe pas correctement. Alors, bien sûr, on peut contourner, mais j'ai par habitude de ne pas faire de choses hasardeuses lorsqu'il s'agit du noyau.
Voilà pourquoi je regrettais que les 2.6.10 et Cie n'étaient pas présents dans testing, ...
Merci pour les réponses en tout cas.
-
[^]Re: Oui, mais ...
Posté par fabb () le 06/03/2005 à 12:58. (lien). Évalué à 1.> Par contre, comme Debian applique très peu de patchs (contrairement à Redhat
Faut te renseigner, depuis Fedora Red Hat applique peu de patch. Leur objectif est de bosser le plus possible en upstream. Il n'y a que RHEL qui est beaucoup patché.
Faut bien comprendre que les distributeurs ne font pas ça de gaité de coeur. C'est une nécessité.-
[^]Re: Oui, mais ...
Posté par Brice Goglin () le 06/03/2005 à 14:17. (lien). Évalué à 1.> Faut te renseigner, depuis Fedora Red Hat applique peu de patch.
C'est pour ca que j'avais dit Red Hat et pas Fedora...-
[^]Re: Oui, mais ...
-
-
-
-
-
Pas de ports ps2 en 2.6.11
salut,
depuis le 2.6.5 compilé avec les sources kernel.org aucun soucis (2.6.7, 2.6.9, 2.6.10 actuellement)
mais lors de la compil du 2.6.11 avec la configuration du 2.6.10, au reboot tout se passe bien aucune erreur sauf que mes ports ps2 ne marchent plus.
pas de clavier et pas souris. n'ayant rien toucher à la configuration, et en ayant vérifié à plusieurs yeux que tous les modules nécessaires au ps2 avaient été compilés, je n'ai pas résolu l'affaire !
suis je le seul?
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
pour la carte.
et la souris logitech usb/ps2 IR 3 boutons clavier ps2 de base .
testé avec et sans les driver nvidia
testé module dans et hors noyau
aucune erreur, X se charge mais pas de souris
a+
-
[^]Re: Pas de ports ps2 en 2.6.11
Posté par herodiade () le 06/03/2005 à 10:08. (lien). Évalué à 4.As-tu une machine Dell ?
Si oui, peut-être devrait tu essayer le 2.6.11.1 (http://www.kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/)(...)-
[^]Re: Pas de ports ps2 en 2.6.11
Posté par ebdomino (page perso, ) le 08/03/2005 à 07:55. (lien). Évalué à 1.Je n'ai pas de machine Dell, je jette un oeil quand même, je te remercie. D'apprès mes recherches sur le net je suis le seul à avoir ce soucis c'est bizarre .
a+-
[^]Re: Pas de ports ps2 en 2.6.11
Posté par ebdomino (page perso, ) le 09/03/2005 à 09:54. (lien). Évalué à 1.re,
merci beaucoup herodiade je viens de compiler le 2.6.11.1 et ma souris fonctionne.
a+
-
-
drm et dc10 \o/
J' ai lu le changelog et pour moi 2 de bonnes nouvelles :
le module drm des ati r2** est amélioré ( vérifié ET tourne mieux).
et le module zoran mjpeg est amélioré (peut être que je pourrais capturer en couleur maintenant)
\o/
L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.