Bon, vu que j’ai devie du sujet original sur un autre thread, je me suis dit qu’il vallait mieux finir de reflechir sur cette question existentielle par ici. La question existentielle etant : ‘pourquoi sur un vieux P4 IA-32, choper 3Go de ram c’est pas aussi simple qu’il n’y parait’.
Donc pour ceux qui n’auraient pas suivi la discussion, ca a commence par la.
On en est presque arrives aux mains avec Glop, mais en poussant mes investigations un peu plus loin, il reste un truc pas clair :
Reprenons. Le P4 dispose bien physiquement de 36 lignes d’adresses (espace addressable de 64Go, via l’activation du mode PAE du cpu, en realisant une pagination pour que l’OS puisse bien adresser plus de 32 bits a savoir 4Go) - info verifiee dans les datasheets d’Intel (http://www.intel.com/design/pentium4/datashts/298643.htm pour les acharnes)
Si on regarde la phase d’initialisation du CPU tel que decrit dans la doc du P4 (http://www.intel.com/design/Pentium4/manuals/253665.htm toujours pour les acharnes, chapitre 9, section 9.1.1 ‘Processor state after reset’), on lit bien que le CPU va commencer a executer son code en mode ‘real address mode’, en d’autres termes, PAE desactive.
Ce qui me chiffonne ici c’est que :
Le bios de ma carte mere (une vieille P4P800) ne fait rien pour activer le PAE au boot - Pas dramatique en soi, du moment qu’il arrive a trouver un truc a booter on s’en tape.
Windows XP, cense gerer le PAE ne l’active manifestement pas tout seul (c’est pourtant pas bien complique que d’aller piocher dans les control registers pour savoir si le CPU supporte ou non le PAE), et donc semble continuer tranquillement en real address mode, quitte a planter lamentablement (BSOD) des que la charge memoire totale physique geree par l’OS depasse la limite fatidique des 4Go.
Linux lui dans sa grande tradition du ‘tu compiles ton kernel en fonction de ton hard’ n’active pas le PAE tant qu’on ne lui demande pas (en meme temps, linux ne se revendique pas non plus ‘plug&play’).
Bref, au final, et contrairement a certaines reponses acerbes, mon calcul est bien fonde puisque le PAE n’est pas active, et que l’on est bien limite a un espace d’adressage de 32 bits de l’OS, et que mes connaissances vis a vis de la gestion de la memoire des OS ne m’ont fait pas defaut. (notepour le baron : bah finalement non j’avais pas mon flag HIGHMEM d’ou le blocage quand ca depassait les 4Go vu que sans HIGHMEM, pas de PAE, mea culpa).
Pour conclure, j’aurais donc une question toute bete : Pourquoi cet empaffe de windobe ne m’active pas le PAE comme un grand? Faut-il que je le prenne par la main pour lui expliquer que non, mon XP ne tourne pas sur un vieux P3, mais sur un P4 qui sait gerer 36 bits d’adresses pour me remapper les I/Os ou il veut du moment que ca vient pas taper dans ma RAM?
Je comprends pas pourquoi tu parles d’adressage 36bits alors que dans ton cas un simple adressage 32bits devrait suffire vu que t’as que 3go de ram. Sinon, je sais pas quelle carte mere tu as, mais la plupart des cartes meres ne supportent pas plus de 3go de ram (voir 4go pour les modeles recents)
Bah non justement le probleme se pose vu que sans le PAE, 3Go de RAM, 256Mo de CG, 256Mo d’AGP aperture, 64Mo de carte son + le reste pris par les zones d’I/O fait un total depassant les 4Go (d’ou le bios et le reste qui ralent et me bouffent une partie de la ram ou pire plantent mechamment).
En baissant mon aperture a 64Mo je repasse sous les 4Go et plus personne ne rale (solution actuelle qui fonctionne tres bien vu que de toutes manieres, la fameuse regle de l’AGP aperture a 2x la ram de la carte c’est completement bidon).
Mais pour aller jusqu’au bout du probleme, j’aimerais bien reussir a faire marcher le tout proprement avec les 256Mo d’aperture, histoire de voir comment winwin se demerde cote PAE (et comme le total de tout ce qui doit etre mappe par l’OS depasse les 4Go physiques, le PAE et son adressage sur 36 bits est indispensable).
Bon je trouve pas de document technique precis sur le sujet mais, Hecian, tu as tout faux, malgre tes 15 ans d’experience, et c’est Glop qui a juste.
Ton probleme vient surement d’un bleme de config BIOS, que sais je.
Concernant l’architecture du PC, et la connaissant quand meme pas mal (c’est mon metier, IUT Genie electrique et tout ca, si tu veux jouer avec les “experiences”), ton calcul est stupide pour une simple raison:
Il y a l’espace d’adressage memoire.
Il y a l’espace d’adressage des peripheriques.
Les deux espaces sont SEPARES, et c’est d’ailleurs pour ca que IBM (ou Intel, je sais plus) a invente le DMA (Direct Memory Access) car sans lui, les transfert de donnees Memoire <-> peripheriques passait par le CPU, ce qui est passablement idiot.
Donc non, ton calcul est faux: Zone Memoire != Zone I/O.
Attention, il y a des exceptions “BIOS” comme la video 80 columns en direct access memory dans B800, mais ca marchait sous MS DOS ca, quand on avait encore acces au materiel/BIOS. C’est plus le cas avec les OS modernes.
Si je trouve des documents corroborants mes affirmations, j’edite et je link.
Hein?!? la mémoire de la carte graphique et de la carte son est dans l’espace d’adressage du proc???
Et pour ce qui est de l’espace d’adressage des dma, ça veut dire que le cpu ne peut pas accéder directement aux I/O? a t’on deux bus séparés? (cpu <=> dma <=> I/O)
[quote=“gring, post:6, topic: 28181”]Hein?!? la mémoire de la carte graphique et de la carte son est dans l’espace d’adressage du proc???
Et pour ce qui est de l’espace d’adressage des dma, ça veut dire que le cpu ne peut pas accéder directement aux I/O? a t’on deux bus séparés? (cpu <=> dma <=> I/O)[/quote]
J’ai peut etre pas ete assez clair.
A l’origine, les 2 espaces etaient separes:
CPU <=> Memory
CPU <=> I/O
Ca pausait des problemes car le transfert de donnees entre Memoire et I/O necessitait le CPU.
Il y a donc maintenant le DMA:
Memory <=> DMA (via un ordre du CPU) <=> I/O
Notez que les 2 espaces sont TOUJOURS separes, mais le DMA fait un pont entre les deux, ce qui libere le CPU.
Du coup, le CPU peut faire autre chose pendant le transfert des donnees.
LoneWolf
Mouvement du front de liberation des CPUs
[quote=“Hecian, post:4, topic: 28181”]Bah non justement le probleme se pose vu que sans le PAE, 3Go de RAM, 256Mo de CG, 256Mo d’AGP aperture, 64Mo de carte son + le reste pris par les zones d’I/O fait un total depassant les 4Go (d’ou le bios et le reste qui ralent et me bouffent une partie de la ram ou pire plantent mechamment).
En baissant mon aperture a 64Mo je repasse sous les 4Go et plus personne ne rale (solution actuelle qui fonctionne tres bien vu que de toutes manieres, la fameuse regle de l’AGP aperture a 2x la ram de la carte c’est completement bidon).
Mais pour aller jusqu’au bout du probleme, j’aimerais bien reussir a faire marcher le tout proprement avec les 256Mo d’aperture, histoire de voir comment winwin se demerde cote PAE (et comme le total de tout ce qui doit etre mappe par l’OS depasse les 4Go physiques, le PAE et son adressage sur 36 bits est indispensable).[/quote]
non sequitur.
Windows 32 n’attribue que 2 Go au processus utilisateurs (ou 3 Go avec le switch /3GB et encore seulement pour les programmes /LARGEADDRESSAWARE)… Et même si l’OS peut gérer plus que 4 Go, ça ne change rien vu que ton adressage reste sur 32 bits… Le switch /PAE permet au CPU d’adresser jusqu’à 64 GB de RAM, mais vu que ça augmente la taille des repertoires de pages et des tables de pages, tu ne peux pas utiliser le switch /3GB en même temps, donc en clair voilà ce que ça fait le PAE, si tu as plusieurs processus qui tournent en même temps et qui chacun demandent beaucoup de RAM, et ben l’OS saura aller taper dans la mémoire physique… supair. Il y a aussi les AWE si tu veux que ton appli gère directement plus de 4 Go, mais c’est du bourrinage à base de lock direct.
Ah et n’espère pas une seule seconde avoir tes 4 Go de RAM qui s’affichent sous Windows avec une carte mère de base, tu vas avoir des trous partout… Pas assez cher mon fils, il te faut la CM Xeon.
Bof, meme pas impressionne, Bac+5 Ingenieur Systemes & Reseaux ici + 10 ans a taffer dans ce domaine, l’architecture du PC, des stations SUN, HP, IBM, SGI, des serveurs, des clusters, etc… c’est mon metier a moi… Bref, passons a la suite, on est pas la pour comparer la longueur de nos kikis respectifs.
[quote]Il y a l’espace d’adressage memoire.
Il y a l’espace d’adressage des peripheriques.
Les deux espaces sont SEPARES, et c’est d’ailleurs pour ca que IBM (ou Intel, je sais plus) a invente le DMA (Direct Memory Access) car sans lui, les transfert de donnees Memoire ↔ peripheriques passait par le CPU, ce qui est passablement idiot.[/quote]
Houlalala tu melanges absolument tout et n’importe quoi la (ou alors tu blagues, mais j’en doutes). A la base les drivers d’I/Os (genre HDDs, Floppys, CDRoms & Co.) ecrivaient des ordres dans les chipsets des controlleurs et pollaient de maniere active pour attendre les resultats (remplace plus tard par les interruptions), et enfin les transferaient du buffer de la carte, vers la RAM de la machine pour etre traitee par le CPU (genre tu chope tes blocs disques et tu laisse le filesystem remettre de l’ordre dans tout ca vis a vis de sa structure). La DMA a ete inventee pour deplacer les buffers des cartes vers la RAM, point barre. Ceci etant dit, ou ais-je parle des buffers de mes controlleurs disques? Hors sujet donc.
[quote]Donc non, ton calcul est faux: Zone Memoire != Zone I/O.
Attention, il y a des exceptions « BIOS » comme la video 80 columns en direct access memory dans B800, mais ca marchait sous MS DOS ca, quand on avait encore acces au materiel/BIOS. C’est plus le cas avec les OS modernes.[/quote]
Pas tout a fait : le framebuffer d’une carte graphique est DIRECTEMENT adressable par le CPU (pas besoin de balancer du directx ou autre API a la noix pour aller allumer un bete pixel a l’ecran, c’est exactement la meme chose que pour ta ‹ console › texte des vieux bouzins PCs, et c’etait meme deja vrai pour les ZX81, les C64 et autres ‹ ordinateurs › de la grande epoque des peek et poke, de meme que pour les premier framebuffers VGA style hercules & Co. sortis a l’epoque des 386/486… Toujours vis a vis de mon exemple personnel, la RAM embarquee sur la X-fi est elle aussi directement addressable par le CPU pour y coller des samples afin de decharger le CPU de l’alimentation des buffers de la carte (hors mappage de l’espace de l’OS), et pour ne pas charger le PCI avec les transferts DMA qui etaient la methode jusqu’ici pratiquee.
Dans le cas specifique de l’AGP aperture, l’OS est cense (selon les specs, voir reference en fin de post) mapper l’espace specifie au dessus de la RAM physique dans l’espace d’adressage du CPU, on ajoute donc une fois encore 256Mo a notre total.
Bref, on se retrouve bien quand meme avec une base de 3Go de RAM Physique, additionnee de 256Mo de ram de la carte graphique (framebuffer/textures/shaders etc… DIRECTEMENT addressables), 256Mo de pseudo RAM mapee par l’OS via les specs AGP pour l’aperture, 64Mo de la X-fi, et les zones classiquement reservees par le chipset, le PCI, etc… qui se reservent de la place pour les plages addressees par les drivers pour controller les chipsets (non Lone, quand tu balance un ‹ ordre › a ton controlleur IDE, tu ne le fais pas via de la DMA, il faut donc mapper une partie de l’espace de ton chipset dans l’espace du CPU, sinon il n’a aucun moyen d’aller programmer le chipset, va voir le code d’un driver IDE sur un linux ou autre BSD et tu verras comment ca se passe). Toujours dans la meme veine, les Pentiums et suivants gerent les tables MTRR pour bien adapter le comportement du cache du CPU au type de plages addressees (marrant tiens, on y retrouve la RAM de sa carte graphique, mais pourquoi donc informer son CPU d’une zone soi-disant non adressable par lui?)
(je fais référence à : « Bref, au final, et contrairement a certaines reponses acerbes, mon calcul est bien fonde »)[/quote]
Merci beaucoup de ton intervention, ca fait vachement avancer le schmillblick… Si au moins tu argumentais, on pourrait peut-etre voir le defaut de mon calcul. J’attend toujours ceci dit…
Windows 32 n’attribue que 2 Go au processus utilisateurs (ou 3 Go avec le switch /3GB et encore seulement pour les programmes /LARGEADDRESSAWARE)… Et même si l’OS peut gérer plus que 4 Go, ça ne change rien vu que ton adressage reste sur 32 bits… Le switch /PAE permet au CPU d’adresser jusqu’à 64 GB de RAM, mais vu que ça augmente la taille des repertoires de pages et des tables de pages, tu ne peux pas utiliser le switch /3GB en même temps, donc en clair voilà ce que ça fait le PAE, si tu as plusieurs processus qui tournent en même temps et qui chacun demandent beaucoup de RAM, et ben l’OS saura aller taper dans la mémoire physique… supair. Il y a aussi les AWE si tu veux que ton appli gère directement plus de 4 Go, mais c’est du bourrinage à base de lock direct.
Ah et n’espère pas une seule seconde avoir tes 4 Go de RAM qui s’affichent sous Windows avec une carte mère de base, tu vas avoir des trous partout… Pas assez cher mon fils, il te faut la CM Xeon.
Pendant ce temps Windows 64…[/quote]
Hors sujet, je ne parle pas d’utiliser 3Go pour un seul processus, je dirais meme que je m’en cogne completement. Je voudrais juste que windobe VOIE et puisse UTILISER les 3Go, et non seulement une partie (apres il les repartis comme il veut).
D’autre part, le MMU d’un P4 IA-32 de base suffit largement pour gerer les 4Go (du moins en theorie, selon les specs d’Intel), charge reste a l’OS de jouer sur le mappage des differents elements dans un espace 32 bits au moment ou un processus ou un driver a besoin d’une page particuliere, apres avoir Page-Out la section remplacee si necessaire, et dans tous les cas en generant une page-fault pour aller changer le mapping memoire du MMU avant de continuer.
Toujours pas plus argumente, ca en devient lassant… Moi qui pensait trouver ici de vraies reponses, je n’ai pour le moment eu que reponses hautaines et denigrements steriles, pas tres flatteur… Je reitere donc : Au boot un IA-32 n’a pas de PAE active et est donc en mode ‹ direct addressing ›, merci de m’indiquer alors comment le bios et windobe mappent tout ce qu’ils ont cote hard dans 4Go sachant qu’il y a plus physiquement/zones reservees. Ca, ca serait utile au debat.
Sur l’AGP (vivi je link aussi du M$ comme source, ca va faire plaisir aux afficionados) : Universal Accelerated Graphics Port (UAGP)
"Standard properties for Microsoft AGP 3.5 driver :
The GART driver only allocates physical memory and sets up the GART. Creating CPU mapping for that memory is the responsibility of the video port."
Sur l’AGP et L’AGP Aperture : AGP V3.0 Interface Specification
A noter, page 116 et suivantes, je cite :
‹ In general, system software places the AGP aperture above the top of the memory (above the highest
byte of actual physical RAM in the system) in a hole that does not conflict with memory-mapped I/O
registers of system devices. ›
J’ai vraiment tout faux??? Pas si sur…
P.S.: Desole pour le ton aggressif de ce post, mais apres 4 posts du meme style, je me suis dit (a tord?) qu’il valait mieux adopter le meme ton.
4 fois windobe pour 8 messages sur cafzone dont le premier, M$… Premier post t’explique que “windobe” y comprend tant rien qu’il BSOD quand ca depasse ses capacites… qui commence les denigrements? Niveau comparaison de zizis, la aussi, tu rales en ayant ete le premier a mettre en avant tes “15 ans d’experience”. C’est bien joli apres de venir se plaindre de ce que t’as demarré.
Si tu respectes un peu notre boulot et tu donnes le benefice du doute aux trucs avant de venir expliquer, a coup d’affirmations basee sur 2 experiences et de “je sais que j’ai raison” (quote), comment ca fonctionne (mal) peut etre que la on pourra discuter sur un ton plus sympa… J’aurais rien demande de mieux. Au final je pense peut etre pouvoir parler pour Cwiz, en disant qu’on pense juste qu’il y a pas plus sourd que celui qui veut pas ecouter et que ca vaut pas forcement l’effort…
Sans rancunes en plus, c’est vraiment pas si important…
Histoire de resituer un peu ce qui m’amene a parler de ton employeur de la sorte, il se trouve que l’OS qui m’a le plus enquiquinne professionnellement reste windows. Forcement, a force on finit par ne plus trop controller son vocabulaire. Ceci etant dit, je n’ai vu nulle part que la cafzone etait l’antre des adorateurs de Microsoft (humour, pas sarcasme, hein), et je me suis un peu lache. Certes, mal juge de ma part, mea culpa donc. D’un autre cote, on m’aurait balance un classique ‹ ouais, mais ton pingouin/ptit demon ridicule/vieux bousin des annees 70, cote convivialite ca laisse a desirer severe, d’ailleurs ma grand mere ne s’en est jamais remise ›, je n’aurais pas ete vexe ni ne me serais senti insulte. (Pour avoir bosse 6 ans dans des boites americaines - dont une partenaire de MS - je sais a quel point les ‹ managers › sont doues pour ‹ embrigader › les troupes, et amener les employes a defendre becs et ongles leur societe - j’ai donne, mais la aussi, un peu de recul permet de ne pas forcement prendre pour toi ce qui s’adresse a la societe, apres tout, la qualite d’un soft/OS depend aujourd’hui tres rarement d’une seule personne)
Vis a vis de la mention de mon experience en la matiere, c’etait plutot en reaction au ‹ essaye plutot de comprendre comment ca fonctionne et ca a ete designé avant de critiquer › qui m’a paru sous-entendre que j’etais un de ces gamins qui apres avoir appris 2-3 mots de vocabulaire les ressortent sans savoir a quoi ca correspond. Bref, mon cote sanguin a encore parle, re-mea-culpa.
Pour le reste j’ai plus de compassion que de respect vis a vis des codeurs de MS, et pour cause : contrairement aux HP, SUN, IBM, SGI et compagnie, vous devez vous taper un historique bien lourd cote retro-compatibilite, un ‹ catalogue › de produits tiers plus qu’heteroclite, et a force d’ajouter toujours un peu plus de fonctionnalites (dont on pourrait discutter de l’opportunite), forcement la quantite massive de code a maintenir n’aide vraiment pas. Pour le cote ‹ sourd › c’est pas vraiment ce qui (a mon humble avis) me caracterise le mieux concernant des discussions autour des OS et des architectures. J’ai eu la chance de pouvoir toucher a beaucoup de choses tres diverses, et ai donc pris beaucoup de recul vis a vis de tout ca. Neanmoins, je reproche tout de meme a une bonne majorite des ‹ afficionados › des produits Microsoft d’avoir un peu tendance a vite considerer qu’hors Windows, point de salut (forcement, a force de se heurter a ce genre de profil, j’ai moi aussi tendance a shooter avant de sympathiser).
Amende honorable etant (je l’espere) faite, on devrait pouvoir repartir sur de bonnes bases et chercher a comprendre pourquoi une config comme celle la (qui n’est surement pas unique de nos jours, du moins tant que les 64 bits n’auront pas completement remplace le 32 bits) pose ce genre de problemes. J’ai apporte le maximum de details vis a vis de ma comprehension de l’architecture du PC et de ce que ca peut impliquer, reste que si ‹ theoriquement › ca devrait passer, en pratique ca ne semble pas aussi simple (maintenant il est vrai que je n’ai pas la meme experience sur Windows que je peux en avoir sur des *nix, et que je ne connais donc pas toutes les options du boot.ini, des clefs de registre permettant de tuner au mieux son kernel, etc…).
Enfin, si mon avis vis a vis des defauts de windows t’interesse toi ou ton employeur, je suis a ton entiere disposition pour en discutter tranquillement en PM ou par mail (si ca c’est pas de l’ouverture d’esprit, je sais pas ce que c’est :P).
[quote]Hors sujet, je ne parle pas d’utiliser 3Go pour un seul processus, je dirais meme que je m’en cogne completement. Je voudrais juste que windobe VOIE et puisse UTILISER les 3Go, et non seulement une partie (apres il les repartis comme il veut).
D’autre part, le MMU d’un P4 IA-32 de base suffit largement pour gerer les 4Go (du moins en theorie, selon les specs d’Intel), charge reste a l’OS de jouer sur le mappage des differents elements dans un espace 32 bits au moment ou un processus ou un driver a besoin d’une page particuliere, apres avoir Page-Out la section remplacee si necessaire, et dans tous les cas en generant une page-fault pour aller changer le mapping memoire du MMU avant de continuer.[/quote]
Tu as lu ma réponse trop rapidement… Je traduis/reformule…
Traduction : Windows gère sans problème de grandes quantités de mémoire, mais dans la pratique sur une machine 32 bits l’utilité est très limitée et je ne suis pas certain que si tu te contentes de voir ce qu’affiche l’about box tu puisses en déduire quoi que ce soit…
Traduction : ton problème est sans doute hardware, refais les mêmes tests avec une carte mère haut de gamme qui sait vraiment gérer 3 Go ou plus. Je te confirme que si ta carte mère gère bien 4 Go alors Windows aussi.
Je ne comprends pas ta question. Tu veux savoir comment Windows utilise les 4 Go physique ? Mais Windows a un système de mémoire virtuelle, donc la question ne se pose pas, la mémoire physique est dans sa grande partie gérée à la discrétion de la VMM. A un instant t une page peut être n’importe où en mémoire physique.
Ou bien tu veux savoir comment l’espace de chaque processus de 4 Go est séparé ? Je te l’ai dit, 2 Go pour le processus user, 2 Go pour le noyau, avec quelques petits espaces aménagés (par exemple les 64 premiers ko sont interdits à tout le monde).
Ou bien comme je te l’ai dit je n’ai vraiment pas compris ta question ?
Bon, je persiste. En tant que formateur, j’aime reussir a convaincre les gens de comment ca marche, meme si ceux ci ont des mauvaises idees preconcues.
Concernant mes etudes et pour finir avec les gros zizi, je precisait juste que j’ai fait un IUT GEII (suivi d’une licence jusqu’au DESS en info) car je pense (j’ai peut etre faux) que ce genre de formation est plus proche du materiel qu’un diplome d’ingenieur (qui doit voir les choses de plus haut).
Ensuite, les remarques acerbes sont la parce que tu fais des affirmations (fausses) et quand on te dis que non, tes affirmations sont fausses et donc tes conclusions par rapport a tes problemes sont errones, tu te braques. Je passe sur le denigrement de windows, de mon point de vue, ca n’a rien a voir, vu que tu n’a apparament pas compris comment fonctionne un PC actuellement:
Cette comprehension est fausse.
Je connais les deux lascars - Cwiz & Gloppy - pour te dire que, si j’avais dis une connerie dans mon explication, il me l’aurait dit. Et c’est aussi leur metier.
Bref, je reprends du debut.
Tu considere l’espace d’adressage memoire comme etant « flat », c’est a dire qu’on adresse un peripherique comme on adresse la memoire. C’est vrai sur certaines architectures (comme le 68hc11), mais pas sur le pc.
J’ai fait des recherches sur le net. D’ailleurs, tes livres n’ont pas d’interet, je vais pas les commander expres pour te prouver ton erreur. Trouve nous plutot des documents Internet prouvant ta version.
Voici les documents prouvant la mienne: Gestion memoire dans Windows 2000
Le document est interessant car il parle des « temps anciens ». Je tiens d’ailleurs a preciser que, depuis windows 2000, plus personne utilise le mode reel (640k + la memoire haute) : Linux (all version), win2000, 2003 et XP utilisent le mode protege.
Il explique tres bien comme fonctionne la memoire dans ces deux modes.
Maintenant, les I/O.
J’ai surtout trouve des bases linux, mais c’est la documentation la plus facile a trouver sur le net. C’est valable globalement pour tout le monde, y compris Windows. I/O Access Abstractions I/O Mapped access I/O Programming
Qu’est ce qui se passe?
Je persiste pour dire que l’adressage I/O est separe de la memoire. En revanche, il existe un systeme pour transferer facilement des donnees entre la memoire et la memoire du peripherique: C’est ce qu’on appelle les I/O Mapped access. Je pense que la confusion vient de la, et j’en avais parle avec B8000 sous DOS.
Je cite:
[quote]Pas tout a fait : le framebuffer d’une carte graphique est DIRECTEMENT adressable par le CPU (pas besoin de balancer du directx ou autre API a la noix pour aller allumer un bete pixel a l’ecran, c’est exactement la meme chose que pour ta ‹ console › texte des vieux bouzins PCs, et c’etait meme deja vrai pour les ZX81, les C64 et autres ‹ ordinateurs › de la grande epoque des peek et poke, de meme que pour les premier framebuffers VGA style hercules & Co. sortis a l’epoque des 386/486… Toujours vis a vis de mon exemple personnel, la RAM embarquee sur la X-fi est elle aussi directement addressable par le CPU pour y coller des samples afin de decharger le CPU de l’alimentation des buffers de la carte (hors mappage de l’espace de l’OS), et pour ne pas charger le PCI avec les transferts DMA qui etaient la methode jusqu’ici pratiquee.
Dans le cas specifique de l’AGP aperture, l’OS est cense (selon les specs, voir reference en fin de post) mapper l’espace specifie au dessus de la RAM physique dans l’espace d’adressage du CPU, on ajoute donc une fois encore 256Mo a notre total.[/quote]
Bon, c’est vrai et c’est faux ton machin.
On va voir deux cas de figure, et je vais essayer d’etre clair:
Imaginons un vieux pc qui n’a que 512ko (kilo) de ram. Le BIOS a cree une pseudo memoire dans l’espace d’adressage B0000-BFFFF pour la gestion de l’affichage texte. Cette memoire n’existe pas physiquement au niveau de la ram, mais existe au niveau de la carte video.
Maintenant, un vieux pc qui a 4Mo de ram. En mode reel, il a 640Ko plus 3Mo de memoire etendu (XMS ou EMS, don’t care). La memoire physique entre 640Ko et 1Mo est perdu pour la gestion des peripherique, car on fait un remapping de cette memoire pour les peripherique. C’est pour ca qu’on pouvait optimiser la RAM du DOS en precisant I=B0000-B7FFF a EMS pour utiliser cette partie de memoire physique quand on avait pas de moniteur monochrome.
De la meme maniere pour la video 'graphique", on avait l’espace A0000-AFFFF qui pouvait etre utilise, notamment via la norme VESA (j’ai fait beaucoup de travaux dessus, je connais(sais) pas mal). On voit qu’on a 64K de ram pour faire notre image. Cela convient pour des images 320x200, mais VESA pouvait faire beaucoup mieux (genre 640x480). Dans ce cas, on avait un systeme de changement de page. On disait a VESA:
_Je veux remplir la page 0
_Transfert des pixel dans la ram A0000-AFFFF (les 64K premiers octets)
_Je veux remplir la page 1
_Transfert des pixel dans la ram A0000-AFFFF (les 64K suivant)
Et ainsi de suite. (note: ma carte VESA (cirrus logic) avant un taille de page de 4ko, donc on remplissait que 4k des A0000-AFFFF et on changeait de page - un peu plus long)
Le principe est le meme avec les framebuffer et tout ces autre trucs: C’est ce qui est explique dans le document « i/o mapping »: On dit au systeme que la ram presente entre telle et telle adresse devrait etre envoye dans la memoire du peripherique. C’est une memoire EXISTANTE. Physique. Donc c’est pas 3Go + 256 + 256. Les 256 sont VIRTUELLEMENT adresses DANS la memoire physique. Techniquement, c’est donc une sorte de « perte de memoire » puisque materiellement, on a effectivement 3Go + 256 +256 +etc.
Pour finir avec ca, je te demanderais (pour bien te montrer) ou se situe, dans l’espace d’adressage memoire, les peripheriques? Parce que remapper la memoire des unites dans la ram, c’est bien joli, mais quid des commandes, des registres, de ces unites? Dans la ram aussi? Ou? Au debut? A la fin? Comment ca marche si j’ai que 512? 1Go? Les registres changent de place?
J’ai jete un oeil a ton document sur l’AGP 3.0, et notamment a ta citation. Je n’ai pas trouve de solution quand le systeme fait 4Go de ram. Ou se place l’aperture? Et meme si c’est le cas pour l’AGP, je peux t’assurer que c’est pas le cas pour tous les peripheriques.
J’espere que j’ai ete clair. Je pense pas pouvoir faire mieux. Si tu me crois pas, tant pis, j’abandonne. J’estime avoir fait beaucoup pour te faire comprendre ton erreur. Je ne peux que demander a Glop et Cwiz de fournir d’autres documents corroborants (ou non, je peux m’etre trompe) mes dires.
edit: Juste pour dire qu’on est 4 a te dire que tu te trompes, tu devrais peut etre te pauser des questions, non?
[quote=« LoneWolf, post:15, topic: 28181 »]J’ai fait des recherches sur le net. D’ailleurs, tes livres n’ont pas d’interet, je vais pas les commander expres pour te prouver ton erreur. Trouve nous plutot des documents Internet prouvant ta version.
[…]
J’espere que j’ai ete clair. Je pense pas pouvoir faire mieux. Si tu me crois pas, tant pis, j’abandonne. J’estime avoir fait beaucoup pour te faire comprendre ton erreur. Je ne peux que demander a Glop et Cwiz de fournir d’autres documents corroborants (ou non, je peux m’etre trompe) mes dires.
edit: Juste pour dire qu’on est 4 a te dire que tu te trompes, tu devrais peut etre te pauser des questions, non?
LoneWolf
Truth must win.[/quote]
Dire que les bouqins de Tannenbaum et de McKusick n’ont ps d’interet alors qu’ils sont des REFERENCES pour tout designer d’OS, et qu’ils sont des Ph.D en Systemes, professeurs emerites, tout autant qu’a la base du design de moults OS, la, tu m’excusera, mais ca passe pas… De plus, l’un comme l’autre traitent d’une implementation x86 qui sont donc tout a fait appropriees a notre propos. Bref, on fera sans malgre tout.
[quote]Voici les documents prouvant la mienne:
Gestion memoire dans Windows 2000
Le document est interessant car il parle des « temps anciens ». Je tiens d’ailleurs a preciser que, depuis windows 2000, plus personne utilise le mode reel (640k + la memoire haute) : Linux (all version), win2000, 2003 et XP utilisent le mode protege.
Il explique tres bien comme fonctionne la memoire dans ces deux modes.[/quote]
Ce document ne fait que parler de generalites sur la realisation du mapping ‹ virtuel › au travers de MMUs, rien ne vient vraiment me contredire par la.
[quote]Qu’est ce qui se passe?
Je persiste pour dire que l’adressage I/O est separe de la memoire. En revanche, il existe un systeme pour transferer facilement des donnees entre la memoire et la memoire du peripherique: C’est ce qu’on appelle les I/O Mapped access.[/quote]
Voyons en detail ce que dit ‹ I/O Mapped Access › :
[quote]bus is an address you pass to devices. E.g., what you’d write to a
PCI bus-mastering DMA device for its target address. To access a bus
address from kernel C code, known as memory-mapped I/O, you must use
ioremap() to convert it to an ioremap address. From C code, these
should always be accessed through readl(), writel() etc. and not as
ordinary memory references. See <asm/io.h>.
phys is a CPU address after MMU translation. It only appears in page
tables and things related to page tables. Even this is hidden to some
extent because pte_page(*pte) returns a virt address despite appearances.
See <asm/pgtable.h>.
virt is a kernel direct-mapped address. These are addresses you can
read and write from C, that correspond to main memory. E.g., on x86,
the virt address 0xc0001000 means the 4097th byte of main memory. See
<asm/page.h>.
[…]
ioremap addresses are returned by ioremap(), which takes a bus
address. These have some similarity to vmalloc addresses, but you can
only use readl(), writel() etc. to access the device memory referred to
here. Unhelpfully, just reading and writing these directly does work on
some architectures, and most older device drivers still do this.
[…]
Virtual map
…
This is what C code sees in user mode:
0x00000000-0xbfffffff User space virtual memory mappings.
This is what C code sees in kernel mode:
0x00000000-0xbfffffff User space virtual memory mappings (current->mm context).
0xc0000000-0xc3ffffff 64MB kernel view of all of main memory, uses 4MB pages.
0xc4000000-0xc47fffff 8MB unmapped hole. 0xc4800000-0xffffbfff Kernel virtual mappings for vmalloc() and ioremap(). 0xffffc000-0xffffcfff Memory mapped local APIC registers.
0xffffd000-0xffffdfff Memory mapped IO-APIC registers.
The 64MB view is subdivided like this (it depends on the PC’s details):
0xc0000000-0xc00003ff Zero page, reserved for BIOS.
0xc0000000-0xc009ffff Low memory (first 640k minus zero page). 0xc00a0000-0xc00fffff Low memory-mapped I/O (especially VGA adapter) and ROMs.
0xc0100000-0xc3ffffff High memory (remaining 63MB).
[…]
On an i386 architecture, bus addresses and phys addresses are the
same. This is convenient but it does tend to hide some problems. On
other architectures, these two are often different.
Devices with bus addresses are supposed to be memory mapped using
ioremap(), and then accessed using readl(), writel() etc. Because none
of this was necessary on the i386 with the 2.0.x kernels, and the other
platforms weren’t very well supported then, many older device drivers
simply access device bus addresses as if they were memory.
Note: there is an ironic twist. The virtual address returned by
ioremap() is not a virt address, so you can’t expect meaningful
results if you pass it to virt_to_bus() or virt_to_phys().
Another note: at least on a PC, you don’t need ioremap() to access
devices in the first 1MB of the bus address range. This includes most
ISA devices (but not video cards).[/quote]
ioremap() est justement la pour pouvoir adresser les segment bus depuis l’espace d’adressage du CPU (phys / virt si tu preferes, phys correspondant aux plages d’adresse APRES translation par le MMU).
Je cite un extrait du contenu du ‹ io.h › d’un kernel linux, et donnant justement la definition de ces fonctions :
[quote]/**
ioremap - map bus memory into CPU space
@offset: bus address of the memory
@size: size of the resource to map
[b]* ioremap performs a platform specific sequence of operations to
make bus memory CPU accessible via the readb/readw/readl/writeb/
writew/writel functions and the other mmio helpers. The returned
address is not guaranteed to be usable directly as a virtual
address. [/b]
*/
static inline void __iomem * ioremap(unsigned long offset, unsigned long size)
{
return __ioremap(offset, size, 0);
}
[…]
/*
readX/writeX() are used to access memory mapped devices. On some
architectures the memory mapped IO stuff needs to be accessed
differently. [b]On the x86 architecture, we just read/write the
Nous disons donc ici exactement la meme chose (enfin ‹ telle adresse devrait etre envoyee dans la memeoire du periph. › non justement c’est la que tu te trompes, pour le calcul cependant, on y arrive doucement mais surement). Les mecanismes que tu evoque juste avant sont des reliquats de l’impossibilite des CPU pre-pentium a adresser plus d’une page d’une traite, il fallait donc pouvoir mapper un a un les segments de la carte video pour la remplir entierement.
Oui, ils changent de place, et c’est justement le boulot de ioremap() que de determiner et renvoyer aux drivers leur addresse dans l’espace d’adressage du CPU (revois ma citation de ‹ I/O mapped access ›).
Quand je parle de 3Go + 256 + 256, c’est :
3Go de RAM physique
256Mo de RAM physique de la CG
256Mo de RAM physique de la CG (la meme, enfin plus precisement 256Mo quand ton aperture est a 256Mo, 64M si 64, etc…) utilisant un mecanisme specifique a l’AGP (l’AGP aperture) pour des raisons de continuite de la zone mappee dans l’espace du CPU, pour permettre au CPU de realiser des copies rapidement (du fait que tu n’as pas a gerer l’eclatement’ du mapping de la RAM de la CG. En clair tu vas pouvoir copier en bloc tes textures ou tes bitmaps destinnees a la partie affichee, sans te preocupper des limites de pages imposees par la virtualisation (on parle toujours d’espace virtuel, vu du kernel/drivers, et non des process user).
(autre citation de la spec AGP)
[quote]AGP Master devices have a certain amount of memory resources that must be placed somewhere in the system memory address map using a PCI base address register. These memory resources fall into two categories, prefetchable and non-prefetchable, address regions. Prefetchable memory space is generally where the linear frame buffer is mapped to provide performance improvements. Nonprefetchable memory space is generally where control registers and FIFO-like communication interfaces are mapped. Each of these address regions should have its own base address register.
See the PCI Local Bus Specification for a description of PCI base address registers.
[…]
In an AGP3.0 system, driver software and an AGP3.0 device can share large amounts of data through buffers placed in system RAM. A large buffer requires many host processor virtual pages; although host system software ensures that these pages appear contiguous to host software (virtually contiguous). It is often difficult for system software to map these virtual pages to contiguous physical pages in system memory (physically contiguous). Thus, in the absence of any sort of remapping mechanism, these pages appear non-contiguous to the rest of the system and require scatter/gather hardware in each device that will access the buffers to deal with the discontinuity.
Like AGP, AGP3.0 provides a solution to this problem in the form of an AGP Graphics aperture. The AGP aperture is a physically contiguous range of the physical address space where AGP3.0 Master accesses directed to it are re-mapped (translated) to potentially physically non-contiguous pages. AGP3.0 Master translation is accomplished through the AGP Graphics Aperture Re-mapping Table (GART). For the purposes of translation, the AGP aperture range is split into a series of aligned regions, each such region is termed an AGP aperture page. Each AGP aperture page has a corresponding translation in the GART.[/quote]
On en arrive petit a petit a la meme conclusion, merci de participer L’OS a effectivement un probleme pour placer toutes ces ressources dans un espace coherent de 4Go, qu’il soit capable ensuite d’organiser via translation (MMU) pour les presenter de maniere uniforme aux drivers (c’est le boulot d’un OS que de donner une vue ‹ abstraite › des ressources physiques, pour simplifier le developpement des drivers - et en bout de chaine des applications, qui elles traitent avec des APIs).
Le but de ton post est clairement de mettre en avant un ego mis à mal et il me paraît évident que tes connaissances approximatives en architecture des systèmes d’exploitation sont ombragées par un désir d’avoir raison coûte que coûte, quel que soit le sujet.
Tu parlais au début de savoir pourquoi tu n’avais pas toute ta RAM affichée sous winwin, tu as eu des réponses (dont des réponses absolument géniales de ma personne) et là maintenant tu nous assènes un “On en arrive petit a petit a la meme conclusion, merci de participer”… Mais wtf, quelle conclusion ?
Je n’en vois qu’une, cet haïku improvisé :
Je suis pénitent,
Tombé dans un troll béant,
Oblivion m’attend.
Bon en fait j’avais poste autre chose, mais au final je jette l’eponge : Manifestement avoir prononce les mots tabous de ‘winwin, windobe, M$’ et autres trucs du genre a attire sur ce thread (a la base destinne a ne pas venir polluer une news concernant un Dell), les adorateurs de bilou, qui se dechainent a coups de hors sujet, de superbes arguments du style ‘t’as tord t’y connais rien’ et autres trolls, sans ne jamais argumenter une seule seconde ni meme remettre en question leurs propres certitudes.
Le seul qui aie vraiment fait l’effort de se documenter, et d’apporter quelque chose a la discussion a ete Lone (Chapeau Bas l’ami, au moins ca a le merite de sortir du lot et de demontrer par l’exemple ce que tu evoquait dans ton post : ‘Bon, je persiste. En tant que formateur, j’aime reussir a convaincre les gens de comment ca marche, meme si ceux ci ont des mauvaises idees preconcues.’, ce qui pour info, etait aussi ma motivation dans mes interventions ici). On est pas encore tout a fait d’accord sur le fond, mais je crois que si on avait un peu continue dans cette voie on aurait fini par faire converger nos points de vue, et finalement trouve ce qui fait merder cette config quand on y colle un aperture de 256Mo (quelques points du fonctionnement de l’aperture ne me sont pas encore completement clairs, je vais aller fouiller un peu le code AGP d’un BSD/Linux pour tenter d’y voir plus clair. Si la suite t’interesse, fais-le moi savoir en PM, au moins on apprendra quelque chose tous les deux. (Contrairement a ce que tu as dis : ‘Ensuite, les remarques acerbes sont la parce que tu fais des affirmations (fausses) et quand on te dis que non, tes affirmations sont fausses et donc tes conclusions par rapport a tes problemes sont errones, tu te braques.’ Je ne me braque pas, mais j’apporte mes arguments (on m’en laisse peu le temps - voir paragraphe precedent…). Si je les epuise ou que tu me colles devant un argument irrefutable, ne t’inquiete pas je reverrais ma copie - il n’y a que les imbeciles qui ne changent pas d’avis - mais pour en arriver la il faut qu’on avance tous les deux).
Pour le reste, ben voila, si vous savez lire, vous avez les references des bouquins pour vous instruire un peu, pour le reste google, freebsd.org, http://lxr.linux.no/source/, intel.com et autres sites permettant d’aller vous meme vous renseigner et voir comment ca fonctionne a bas niveau et dans un kernel, vous seront d’un bien plus grand secours que toute doc marketting issue de votre secte, ou autre idee preconcue source d’autant d’ignorance (et dire que l’on croyait les guerres de religion terminees, nous revoila envahis de fanboys, pas sur que l’on aie gagne au change).
Pour ta gouverne l’ami moloch, la conclusion (si tu avais un tant soit peu lu) est de voir que pour un IA32, on approche de problemes d’adressage dus a la limite des 4Go. Que quand on regarde de plus pres les details d’implementation, effectivement, 3Go + divers peripheriques consomment tout l’espace disponible au KERNEL, et qu’il est donc necessaire soit de jouer sur des parametres style AGP aperture pour repasser en dessous de la barre (merci, mais je ne t’ai pas attendu pour trouver la solution, encore une fois tu n’as pas compris le but de ce thread), ou sinon la RAM disponible sera amputee (au mieux), ou l’OS sera instable (le XP qui BSOD quand la charge memoire a depasse environ 2.7Go m’est rellement arrive, sur une machine proprement et fraichement installee/service packee/patchee - 100% reproductible, au passage). Alors ‘Mais wtf, quelle conclusion ?’, ben apres deux hors sujet en deux posts je ne m’etonne pas que tu te poses encore la question…
while{1}
{
Je t’ai dit trois fois que c’était ta carte mère le problème…
C’est pas un problème d’OS…
La plupart des cartes mères du marché ont beaucoup de mal au delà de 3 Go (même 2 Go), quoiqu’il puisse être marqué sur la notice…
Essaye avec une carte mère qui a un chipset i7xxx…
J’ai fait tourner un Windows avec 6 Go de RAM sur Xeon IA32, PAE activé…
}
