Non, on ne parle pas du deuxieme mais du troisieme nombre.
Linus avait proposé il y a qqs mois que 2.6. soit stable alors que
2.6. serait instable.
Ca a été abandonné, tous les 2.6 pair et impair sont considérés comme stable.
2.6.13 et la branche 2.6 sont considérés comme stable, en particulier avec les 2.6.13.x qui suivront pour fixer qqs bugs.
L'idée des noyaux impairs instables a été abandonnée.
Je n'ai pas suivi le troll jusqu'au bout sur LKML, est-ce que les resultats de comparaison de la consommation d'energie en 250Hz et 1000Hz ont été concluants ?
Non il ne conserve pas la mémoire. Enfin tout depend du truc que kexec lance. Si tu kexec un noyau linux, il ecrase tout comme n'importe quel boot de noyau linux.
Par contre, kdump utilise kexec avec un tout petit noyau qui a la particularité de ne pas tout ecraser et permet donc d'aller voir la mémoire de l'ancien noyau. Mais kdump ne permet pas de travailler, juste de debugguer un peu.
"pas mal de choses", je sais pas. "un peu", surement.
Mais encore faudrait-il utiliser le bon scheduler.
On parle d'amélioration du scheduler CFQ, mais très peu de personnes ne l'utilisent puisque par défaut c'est l'Anticipatory et qu'on ne sait pas forcément comment le changer...
Non, ca n'est pas une update du noyau qui tourne actuellement.
C'est juste un reboot plus rapide puisqu'il ne passe pas par le BIOS.
Le noyau reboote entierement, toutes les structures de données sont perdues, donc en particulier tes processus.
Donc uptime remis à 0.
On ne peut pas conserver ces structures de données puisque le nouveau noyau pourrait très bien avoir des types différents, par exemple un champ de plus ou de moins dans une structure.
C'est pour la même raison que tu ne peux pas, apres un suspend to disk, utiliser la sauvegarde du systeme avec un autre noyau (il verifie que c'est la meme version).
En effet, mais Linux préfère appeler tous ces versions "rc" au lieu de "pre" puis "rc" comme avant.
Il ne faut plus parler de "rc" pour "release candidate".
"ridiculous counter" a par exemple été proposé à la place.
Comment ca se passe avec les processeurs qui ne sont pas NX-bit ?
J'avais cru comprendre que n'importe quelle page accessible en lecture etait executable sur x86 (avant que NX-bit soit ajouté recemment) ?
Tu as fait make oldconfig pour passer du 2.6.10 au 2.6.12 ?
Les options de config n'ont pas l'air d'avoir changé, c'est toujours
CONFIG_USB_STORAGE pour usb-storage et CONFIG_BLK_DEV_UB pour ub.
Lesquelles as-tu dans tes .config de 2.6.10 et .12 ?
> 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.
> 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.
> 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.
> 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) :
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(...)
> 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...
> 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.
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: RC != deverminage
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 2.
linus avait proposé :
2.6.pair = stable
2.6.impair = instable
[^] # Re: RC != deverminage
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 3.
Linus avait proposé il y a qqs mois que 2.6. soit stable alors que
2.6. serait instable.
Ca a été abandonné, tous les 2.6 pair et impair sont considérés comme stable.
[^] # Re: RC != deverminage
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 3.
L'idée des noyaux impairs instables a été abandonnée.
[^] # Re: Testé et approuvé
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 5.
echo cfq > /sys/block/hda/queue/scheduler
[^] # Re: Testé et approuvé
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 1.
[^] # Re: ...
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 4.
[^] # Re: Plusieurs "reboots" avec kexec?
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 4.
Par contre, kdump utilise kexec avec un tout petit noyau qui a la particularité de ne pas tout ecraser et permet donc d'aller voir la mémoire de l'ancien noyau. Mais kdump ne permet pas de travailler, juste de debugguer un peu.
[^] # Re: RC != deverminage
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 2.
Arcangeli fait encore des noyau -aa ?
[^] # Re: Testé et approuvé
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 5.
Mais encore faudrait-il utiliser le bon scheduler.
On parle d'amélioration du scheduler CFQ, mais très peu de personnes ne l'utilisent puisque par défaut c'est l'Anticipatory et qu'on ne sait pas forcément comment le changer...
macvin:~% cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq
[^] # Re: L'uptime des mediabox home-made va-t-il s'envoler ?
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 10.
C'est juste un reboot plus rapide puisqu'il ne passe pas par le BIOS.
Le noyau reboote entierement, toutes les structures de données sont perdues, donc en particulier tes processus.
Donc uptime remis à 0.
On ne peut pas conserver ces structures de données puisque le nouveau noyau pourrait très bien avoir des types différents, par exemple un champ de plus ou de moins dans une structure.
C'est pour la même raison que tu ne peux pas, apres un suspend to disk, utiliser la sauvegarde du systeme avec un autre noyau (il verifie que c'est la meme version).
[^] # Re: RC != deverminage
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 8.
Il ne faut plus parler de "rc" pour "release candidate".
"ridiculous counter" a par exemple été proposé à la place.
[^] # Re: Toujours pas de reiser4 !
Posté par Brice Goglin . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Il y a Reiser4.
http://lkml.org/lkml/2005/6/21/98/index.html(...)
[^] # Re: +
Posté par Brice Goglin . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
J'avais cru comprendre que n'importe quelle page accessible en lecture etait executable sur x86 (avant que NX-bit soit ajouté recemment) ?
[^] # Re: Toujours pas de reiser4 !
Posté par Brice Goglin . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 6.
Reiser4 est dedans.
[^] # Re: USB ?
Posté par Brice Goglin . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 2.
Les options de config n'ont pas l'air d'avoir changé, c'est toujours
CONFIG_USB_STORAGE pour usb-storage et CONFIG_BLK_DEV_UB pour ub.
Lesquelles as-tu dans tes .config de 2.6.10 et .12 ?
[^] # Re: +
Posté par Brice Goglin . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 6.
# 3 mois et demi, pas 5 mois :)
Posté par Brice Goglin . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 10.
[^] # Re: Il manque
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 2.
Tu peux aussi aller lire directement l'annonce sur la LKML :
http://marc.theaimsgroup.com/?l=linux-ia64&m=110922543030922&w=2
[^] # Re: Il manque
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 3.
> - 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 Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 2.
> 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 Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 4.
> 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 Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 3.
> 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: Oui, mais ...
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
C'est pour ca que j'avais dit Red Hat et pas Fedora...
[^] # Re: Oui, mais ...
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 2.
> 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: Il manque
Posté par Brice Goglin . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
> 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)