Le nouveau noyau Linux 2.6.28 est disponible depuis à peine deux jours,
et il fera date pour tous les utilisateurs un peu avancés des
distributions qui en découlent. Il corrige des problèmes, certes, mais
porte surtout sous les projecteurs deux nouveautés : le Graphics
Execution Manager et le système de fichiers Ext4.
-> Ah, on apprend ici que Linux "avait des problèmes" ben ca alors...
-> Ah, il a des nouveautés: Il n'était donc pas parfait ?
Le but d’Ext4 est d’améliorer les performances et la fiabilité lors des
lectures et écritures des données. Pour tous ceux qui utilisent l’Ext3
actuel, il existe une procédure de migration qui évite le formatage, ce
que beaucoup apprécieront. La taille maximale d’une seule partition
atteint désormais l’exaoctet, ce qui correspond à la bagatelle de 1 000
000 To, soit 1 000 000 000 Go. Par rapport à Ext3, les « nœuds » sont
vérifiés seulement s’ils sont utilisés, une allocation différée des
données a été mise en place, ainsi que la vérification du journal par
une somme de contrôle (checksum).
-> Ah, il y'avait des problèmes d'écritures, de peroformances et de
fiabilité ?
Le Graphics Execution Manager, ou GEM, est un gestionnaire de mémoire
graphique. Il a pour but d’augmenter allègrement les performances. Le
GEM a été développé initialement par deux ingénieurs de chez Intel,
Keith Packard et Eric Anholt. Selon des tests préliminaires, les
performances d’une puce i915 étaient augmentées de 50 à 60 %. Seuls
d’ailleurs les pilotes Intel sont compatibles avec le GEM, mais
l’inclusion dans le noyau promet une prise en charge prochaine par bien
d’autres pilotes.
-> Ca c'est une bonne nouvelle, un jour Linux deviendra plus performant
sur beaucoup de machines. Bon, d'icic là...
Comme d’habitude, le moyen le plus simple d’installer le nouveau noyau
est de lancer le module de mise à jour intégré à la distribution
utilisée.
-> Oui, c'est encore le plus simple. Si on veut compliquer, c'est sûre
qu'ont peu
On Wed, 07 Jan 2009 00:05:51 +0100, Olivier F wrote:
Le nouveau noyau Linux 2.6.28 est disponible depuis à peine deux jours,
[couic]
Depuis le 24 décembre 2008, 23:45 GMT...
-> Linux parfait s'améliore gentiment
Par contre, toi tu viens d'éprouver le Zune Bug?
-- Ed
Jean Bon (de Parme)
On Wed, 07 Jan 2009 00:05:51 +0100, Olivier F <Olivier@ F> wrote:
Le nouveau noyau Linux 2.6.28 est disponible depuis à peine deux jours, et il fera date pour tous les utilisateurs un peu avancés des distributions qui en découlent. Il corrige des problèmes, certes, mais porte surtout sous les projecteurs deux nouveautés : le Graphics Execution Manager et le système de fichiers Ext4.
-> Ah, on apprend ici que Linux "avait des problèmes" ben ca alors...
Toi t'en a un gros de probleme et a moi d'un traitement medicamenteux, y a pas de solution (l'euthanasie n'est pas legale)
-> Ah, il a des nouveautés: Il n'était donc pas parfait ?
Le but d’Ext4 est d’améliorer les performances et la fiabilité lors des lectures et écritures des données. Pour tous ceux qui utilisent l’Ext3 actuel, il existe une procédure de migration qui évite le formatage, ce que beaucoup apprécieront. La taille maximale d’une seule partition atteint désormais l’exaoctet, ce qui correspond à la bagatelle de 1 000 000 To, soit 1 000 000 000 Go. Par rapport à Ext3, les « nœuds » sont vérifiés seulement s’ils sont utilisés, une allocation différée des données a été mise en place, ainsi que la vérification du journal par une somme de contrôle (checksum).
-> Ah, il y'avait des problèmes d'écritures, de peroformances et de fiabilité ?
Debranche et rallume ton PC maintenant et rallume le, que se passe t il ?
Le Graphics Execution Manager, ou GEM, est un gestionnaire de mémoire graphique. Il a pour but d’augmenter allègrement les performances. Le GEM a été développé initialement par deux ingénieurs de chez Intel, Keith Packard et Eric Anholt. Selon des tests préliminaires, les performances d’une puce i915 étaient augmentées de 50 à 60 %. Seuls d’ailleurs les pilotes Intel sont compatibles avec le GEM, mais l’inclusion dans le noyau promet une prise en charge prochaine par bien d’autres pilotes.
-> Ca c'est une bonne nouvelle, un jour Linux deviendra plus performant sur beaucoup de machines. Bon, d'icic là...
Le jour où les futur windows seont aussi performant que windows 2000 l'a été on en reparlera.
Comme d’habitude, le moyen le plus simple d’installer le nouveau noyau est de lancer le module de mise à jour intégré à la distribution utilisée.
-> Oui, c'est encore le plus simple. Si on veut compliquer, c'est sûre qu'ont peu
-> Linux parfait s'améliore gentiment
Tandisque windows devient lourd cherement (comme toi)
On Wed, 07 Jan 2009 00:05:51 +0100, Olivier F <Olivier@ F> wrote:
Le nouveau noyau Linux 2.6.28 est disponible depuis à peine deux jours,
et il fera date pour tous les utilisateurs un peu avancés des
distributions qui en découlent. Il corrige des problèmes, certes, mais
porte surtout sous les projecteurs deux nouveautés : le Graphics
Execution Manager et le système de fichiers Ext4.
-> Ah, on apprend ici que Linux "avait des problèmes" ben ca alors...
Toi t'en a un gros de probleme et a moi d'un traitement medicamenteux,
y a pas de solution (l'euthanasie n'est pas legale)
-> Ah, il a des nouveautés: Il n'était donc pas parfait ?
Le but d’Ext4 est d’améliorer les performances et la fiabilité lors des
lectures et écritures des données. Pour tous ceux qui utilisent l’Ext3
actuel, il existe une procédure de migration qui évite le formatage, ce
que beaucoup apprécieront. La taille maximale d’une seule partition
atteint désormais l’exaoctet, ce qui correspond à la bagatelle de 1 000
000 To, soit 1 000 000 000 Go. Par rapport à Ext3, les « nœuds » sont
vérifiés seulement s’ils sont utilisés, une allocation différée des
données a été mise en place, ainsi que la vérification du journal par
une somme de contrôle (checksum).
-> Ah, il y'avait des problèmes d'écritures, de peroformances et de
fiabilité ?
Debranche et rallume ton PC maintenant et rallume le, que se passe t
il ?
Le Graphics Execution Manager, ou GEM, est un gestionnaire de mémoire
graphique. Il a pour but d’augmenter allègrement les performances. Le
GEM a été développé initialement par deux ingénieurs de chez Intel,
Keith Packard et Eric Anholt. Selon des tests préliminaires, les
performances d’une puce i915 étaient augmentées de 50 à 60 %. Seuls
d’ailleurs les pilotes Intel sont compatibles avec le GEM, mais
l’inclusion dans le noyau promet une prise en charge prochaine par bien
d’autres pilotes.
-> Ca c'est une bonne nouvelle, un jour Linux deviendra plus performant
sur beaucoup de machines. Bon, d'icic là...
Le jour où les futur windows seont aussi performant que windows 2000
l'a été on en reparlera.
Comme d’habitude, le moyen le plus simple d’installer le nouveau noyau
est de lancer le module de mise à jour intégré à la distribution
utilisée.
-> Oui, c'est encore le plus simple. Si on veut compliquer, c'est sûre
qu'ont peu
-> Linux parfait s'améliore gentiment
Tandisque windows devient lourd cherement (comme toi)
On Wed, 07 Jan 2009 00:05:51 +0100, Olivier F <Olivier@ F> wrote:
Le nouveau noyau Linux 2.6.28 est disponible depuis à peine deux jours, et il fera date pour tous les utilisateurs un peu avancés des distributions qui en découlent. Il corrige des problèmes, certes, mais porte surtout sous les projecteurs deux nouveautés : le Graphics Execution Manager et le système de fichiers Ext4.
-> Ah, on apprend ici que Linux "avait des problèmes" ben ca alors...
Toi t'en a un gros de probleme et a moi d'un traitement medicamenteux, y a pas de solution (l'euthanasie n'est pas legale)
-> Ah, il a des nouveautés: Il n'était donc pas parfait ?
Le but d’Ext4 est d’améliorer les performances et la fiabilité lors des lectures et écritures des données. Pour tous ceux qui utilisent l’Ext3 actuel, il existe une procédure de migration qui évite le formatage, ce que beaucoup apprécieront. La taille maximale d’une seule partition atteint désormais l’exaoctet, ce qui correspond à la bagatelle de 1 000 000 To, soit 1 000 000 000 Go. Par rapport à Ext3, les « nœuds » sont vérifiés seulement s’ils sont utilisés, une allocation différée des données a été mise en place, ainsi que la vérification du journal par une somme de contrôle (checksum).
-> Ah, il y'avait des problèmes d'écritures, de peroformances et de fiabilité ?
Debranche et rallume ton PC maintenant et rallume le, que se passe t il ?
Le Graphics Execution Manager, ou GEM, est un gestionnaire de mémoire graphique. Il a pour but d’augmenter allègrement les performances. Le GEM a été développé initialement par deux ingénieurs de chez Intel, Keith Packard et Eric Anholt. Selon des tests préliminaires, les performances d’une puce i915 étaient augmentées de 50 à 60 %. Seuls d’ailleurs les pilotes Intel sont compatibles avec le GEM, mais l’inclusion dans le noyau promet une prise en charge prochaine par bien d’autres pilotes.
-> Ca c'est une bonne nouvelle, un jour Linux deviendra plus performant sur beaucoup de machines. Bon, d'icic là...
Le jour où les futur windows seont aussi performant que windows 2000 l'a été on en reparlera.
Comme d’habitude, le moyen le plus simple d’installer le nouveau noyau est de lancer le module de mise à jour intégré à la distribution utilisée.
-> Oui, c'est encore le plus simple. Si on veut compliquer, c'est sûre qu'ont peu
-> Linux parfait s'améliore gentiment
Tandisque windows devient lourd cherement (comme toi)
Jo Kerr
Jean Bon (de Parme) avait écrit le 07/01/2009 :
Tandisque windows devient lourd cherement (comme toi)
Linux ne s'est pas allégé au fil du temps non plus. OK il est gratuit.
-- In gold we trust (c)
Jean Bon (de Parme) avait écrit le 07/01/2009 :
Tandisque windows devient lourd cherement (comme toi)
Linux ne s'est pas allégé au fil du temps non plus.
OK il est gratuit.
Properly written NDIS drivers will work as-is on PAE systems, but will have a significant negative performance impact that grows as the amount of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura un impact négatif significatif sur les performance et qui grandit à mesure que la quantité de RAM installée augmente.
trop fort Ms -- http://remyaumeunier.chez-alice.fr/
Properly written NDIS drivers will work as-is on PAE systems, but will
have a significant negative performance impact that grows as the amount
of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura
un impact négatif significatif sur les performance et qui grandit à
mesure que la quantité de RAM installée augmente.
trop fort Ms
--
http://remyaumeunier.chez-alice.fr/
Properly written NDIS drivers will work as-is on PAE systems, but will have a significant negative performance impact that grows as the amount of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura un impact négatif significatif sur les performance et qui grandit à mesure que la quantité de RAM installée augmente.
trop fort Ms -- http://remyaumeunier.chez-alice.fr/
Jean Bon (de Parme)
On Wed, 07 Jan 2009 14:02:02 +0100, Jo Kerr wrote:
Jean Bon (de Parme) avait écrit le 07/01/2009 :
Tandisque windows devient lourd cherement (comme toi)
Linux ne s'est pas allégé au fil du temps non plus. OK il est gratuit.
Linux tien sur combien de disquette 1,44Mo ?
Apres si on parle du gestionnaire de fenetre, il y en a de super leger et d'autre tres lourd.
On Wed, 07 Jan 2009 14:02:02 +0100, Jo Kerr <jo.kerr@jo.invalid>
wrote:
Jean Bon (de Parme) avait écrit le 07/01/2009 :
Tandisque windows devient lourd cherement (comme toi)
Linux ne s'est pas allégé au fil du temps non plus.
OK il est gratuit.
Linux tien sur combien de disquette 1,44Mo ?
Apres si on parle du gestionnaire de fenetre, il y en a de super
leger et d'autre tres lourd.
Properly written NDIS drivers will work as-is on PAE systems, but will have a significant negative performance impact that grows as the amount of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura un impact négatif significatif sur les performance et qui grandit à mesure que la quantité de RAM installée augmente.
trop fort Ms
Voici ce que je trouve sur DAC: http://lwn.net/Articles/28092/ Double address cycle addressing The PCI bus is capable of a "double address cycle" (DAC) mode of operation. DAC enables the use of 64-bit DMA addresses, greatly expanding the range of memory which is reachable on systems without I/O memory mapping units. DAC is also expensive, however, and is not properly supported by all devices and buses. So the DMA support routines will normally go out of their way to avoid creating mappings that require DAC - even when the driver has set an address mask that would allow it.
There are occasions where DAC is useful, however. In particular, very large DMA mappings may not be possible in the normal, single-cycle address range. For these rare cases, the PCI layer (but not the generic DMA layer) provides a special set of functions. Note that the DAC functions can be very expensive to use; they should generally be avoided unless absolutely necessary. These functions aren't strictly a 2.6 feature; they were also added to 2.4.13.
Donc il y a bien un mécanisme pour que les périphériques puissent faire des accés DMA en mémoire haute, mais ils sont *onéreux*.
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes physiques.
De même ici l'article de Wikipedia: http://en.wikipedia.org/wiki/Direct_memory_access A modern x86 CPU may use more than 4 GB of memory, utilizing PAE, a 36-bit addressing mode. In such a case, a device using DMA with a 32-bit address bus is unable to address memory above the 4 GB line. The new Double Address Cycle (DAC) mechanism, if implemented on both the PCI bus and the device itself,[1] enables 64-bit DMA addressing. Otherwise, the operating system would need to work around the problem by using costly double buffers (Windows nomenclature) also known as bounce buffers (Linux).
Tant qu'on en est aux traductions:
Un processeur moderne x86 peut utiliser plus de 4 Gigs de mémoire en utilisant le mode PAE, un mode qui utilise des adresses à 36 bits. En un tel cas un périphérique faisant un transfert direct en mémoire sur un bus à 32 bits ne peut pas accéder à la mémoire au dessus de 4 Gigs. Le nouveau mécanisme de "double cycle d'adressage", s'il est implémenté à la fois sur le bus PCI et dans le périphérique, permet d'adresser sur 64 bits. A défaut, l'OS doit contourner le problème en utilisant de coûteux double "buffers" (nomenclature Windows) ou "bounce buffers" nomenclature Linux.
La référence 1 est chez Microsoft qui précise tous les problèmes qui se posent si le bus PCI prétend supporter le DAC, sans le supporter en fait. Bref c'est un merdier total quand la chaîne complète, processeur, bus PCI, périphérique ne supporte pas intégralement des adresses à 64 bits.
Properly written NDIS drivers will work as-is on PAE systems, but will
have a significant negative performance impact that grows as the amount
of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura
un impact négatif significatif sur les performance et qui grandit à
mesure que la quantité de RAM installée augmente.
trop fort Ms
Voici ce que je trouve sur DAC:
http://lwn.net/Articles/28092/
Double address cycle addressing
The PCI bus is capable of a "double address cycle" (DAC) mode of
operation. DAC enables the use of 64-bit DMA addresses, greatly
expanding the range of memory which is reachable on systems without I/O
memory mapping units. DAC is also expensive, however, and is not
properly supported by all devices and buses. So the DMA support routines
will normally go out of their way to avoid creating mappings that
require DAC - even when the driver has set an address mask that would
allow it.
There are occasions where DAC is useful, however. In particular, very
large DMA mappings may not be possible in the normal, single-cycle
address range. For these rare cases, the PCI layer (but not the generic
DMA layer) provides a special set of functions. Note that the DAC
functions can be very expensive to use; they should generally be avoided
unless absolutely necessary. These functions aren't strictly a 2.6
feature; they were also added to 2.4.13.
Donc il y a bien un mécanisme pour que les périphériques puissent faire
des accés DMA en mémoire haute, mais ils sont *onéreux*.
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes
physiques.
De même ici l'article de Wikipedia:
http://en.wikipedia.org/wiki/Direct_memory_access
A modern x86 CPU may use more than 4 GB of memory, utilizing PAE, a
36-bit addressing mode. In such a case, a device using DMA with a 32-bit
address bus is unable to address memory above the 4 GB line. The new
Double Address Cycle (DAC) mechanism, if implemented on both the PCI bus
and the device itself,[1] enables 64-bit DMA addressing. Otherwise, the
operating system would need to work around the problem by using costly
double buffers (Windows nomenclature) also known as bounce buffers
(Linux).
Tant qu'on en est aux traductions:
Un processeur moderne x86 peut utiliser plus de 4 Gigs de mémoire en
utilisant le mode PAE, un mode qui utilise des adresses à 36 bits. En un
tel cas un périphérique faisant un transfert direct en mémoire sur un
bus à 32 bits ne peut pas accéder à la mémoire au dessus de 4 Gigs. Le
nouveau mécanisme de "double cycle d'adressage", s'il est implémenté à
la fois sur le bus PCI et dans le périphérique, permet d'adresser sur 64
bits. A défaut, l'OS doit contourner le problème en utilisant de
coûteux double "buffers" (nomenclature Windows) ou "bounce buffers"
nomenclature Linux.
La référence 1 est chez Microsoft qui précise tous les problèmes qui se
posent si le bus PCI prétend supporter le DAC, sans le supporter en
fait. Bref c'est un merdier total quand la chaîne complète, processeur,
bus PCI, périphérique ne supporte pas intégralement des adresses à 64
bits.
Properly written NDIS drivers will work as-is on PAE systems, but will have a significant negative performance impact that grows as the amount of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura un impact négatif significatif sur les performance et qui grandit à mesure que la quantité de RAM installée augmente.
trop fort Ms
Voici ce que je trouve sur DAC: http://lwn.net/Articles/28092/ Double address cycle addressing The PCI bus is capable of a "double address cycle" (DAC) mode of operation. DAC enables the use of 64-bit DMA addresses, greatly expanding the range of memory which is reachable on systems without I/O memory mapping units. DAC is also expensive, however, and is not properly supported by all devices and buses. So the DMA support routines will normally go out of their way to avoid creating mappings that require DAC - even when the driver has set an address mask that would allow it.
There are occasions where DAC is useful, however. In particular, very large DMA mappings may not be possible in the normal, single-cycle address range. For these rare cases, the PCI layer (but not the generic DMA layer) provides a special set of functions. Note that the DAC functions can be very expensive to use; they should generally be avoided unless absolutely necessary. These functions aren't strictly a 2.6 feature; they were also added to 2.4.13.
Donc il y a bien un mécanisme pour que les périphériques puissent faire des accés DMA en mémoire haute, mais ils sont *onéreux*.
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes physiques.
De même ici l'article de Wikipedia: http://en.wikipedia.org/wiki/Direct_memory_access A modern x86 CPU may use more than 4 GB of memory, utilizing PAE, a 36-bit addressing mode. In such a case, a device using DMA with a 32-bit address bus is unable to address memory above the 4 GB line. The new Double Address Cycle (DAC) mechanism, if implemented on both the PCI bus and the device itself,[1] enables 64-bit DMA addressing. Otherwise, the operating system would need to work around the problem by using costly double buffers (Windows nomenclature) also known as bounce buffers (Linux).
Tant qu'on en est aux traductions:
Un processeur moderne x86 peut utiliser plus de 4 Gigs de mémoire en utilisant le mode PAE, un mode qui utilise des adresses à 36 bits. En un tel cas un périphérique faisant un transfert direct en mémoire sur un bus à 32 bits ne peut pas accéder à la mémoire au dessus de 4 Gigs. Le nouveau mécanisme de "double cycle d'adressage", s'il est implémenté à la fois sur le bus PCI et dans le périphérique, permet d'adresser sur 64 bits. A défaut, l'OS doit contourner le problème en utilisant de coûteux double "buffers" (nomenclature Windows) ou "bounce buffers" nomenclature Linux.
La référence 1 est chez Microsoft qui précise tous les problèmes qui se posent si le bus PCI prétend supporter le DAC, sans le supporter en fait. Bref c'est un merdier total quand la chaîne complète, processeur, bus PCI, périphérique ne supporte pas intégralement des adresses à 64 bits.
--
Michel TALON
Eric Masson
(Michel Talon) writes:
'Re,
<PAE>
Bref c'est un merdier total quand la chaîne complète, processeur, bus PCI, périphérique ne supporte pas intégralement des adresses à 64 bits.
Ben vi, un gros hack bien crade sensé retarder l'évolution inéluctable vers le 64 bits de la plateforme ia32...
-- Car en normandie nous aimons beaucoup le jeu du saute-moutons. Et j'interdis ici les parisiens centralistes et snobinards de profiter de cet aveu pour briller d'un calembour à tendance zoophile et bocagophobe -+- LC in www.le-gnu.net - Sauter n'est pas jouir -+-
talon@lpthe.jussieu.fr (Michel Talon) writes:
'Re,
<PAE>
Bref c'est un merdier total quand la chaîne complète, processeur, bus
PCI, périphérique ne supporte pas intégralement des adresses à 64
bits.
Ben vi, un gros hack bien crade sensé retarder l'évolution inéluctable
vers le 64 bits de la plateforme ia32...
--
Car en normandie nous aimons beaucoup le jeu du saute-moutons. Et
j'interdis ici les parisiens centralistes et snobinards de profiter de
cet aveu pour briller d'un calembour à tendance zoophile et bocagophobe
-+- LC in www.le-gnu.net - Sauter n'est pas jouir -+-
Bref c'est un merdier total quand la chaîne complète, processeur, bus PCI, périphérique ne supporte pas intégralement des adresses à 64 bits.
Ben vi, un gros hack bien crade sensé retarder l'évolution inéluctable vers le 64 bits de la plateforme ia32...
-- Car en normandie nous aimons beaucoup le jeu du saute-moutons. Et j'interdis ici les parisiens centralistes et snobinards de profiter de cet aveu pour briller d'un calembour à tendance zoophile et bocagophobe -+- LC in www.le-gnu.net - Sauter n'est pas jouir -+-
Properly written NDIS drivers will work as-is on PAE systems, but will have a significant negative performance impact that grows as the amount of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura un impact négatif significatif sur les performance et qui grandit à mesure que la quantité de RAM installée augmente.
trop fort Ms
Voici ce que je trouve sur DAC: http://lwn.net/Articles/28092/ Double address cycle addressing The PCI bus is capable of a "double address cycle" (DAC) mode of operation. DAC enables the use of 64-bit DMA addresses, greatly expanding the range of memory which is reachable on systems without I/O memory mapping units. DAC is also expensive, however, and is not properly supported by all devices and buses. So the DMA support routines will normally go out of their way to avoid creating mappings that require DAC - even when the driver has set an address mask that would allow it.
There are occasions where DAC is useful, however. In particular, very large DMA mappings may not be possible in the normal, single-cycle address range. For these rare cases, the PCI layer (but not the generic DMA layer) provides a special set of functions. Note that the DAC functions can be very expensive to use; they should generally be avoided unless absolutely necessary. These functions aren't strictly a 2.6 feature; they were also added to 2.4.13.
Donc il y a bien un mécanisme pour que les périphériques puissent faire des accés DMA en mémoire haute, mais ils sont *onéreux*.
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes physiques.
De même ici l'article de Wikipedia: http://en.wikipedia.org/wiki/Direct_memory_access A modern x86 CPU may use more than 4 GB of memory, utilizing PAE, a 36-bit addressing mode. In such a case, a device using DMA with a 32-bit address bus is unable to address memory above the 4 GB line. The new Double Address Cycle (DAC) mechanism, if implemented on both the PCI bus and the device itself,[1] enables 64-bit DMA addressing. Otherwise, the operating system would need to work around the problem by using costly double buffers (Windows nomenclature) also known as bounce buffers (Linux).
Tant qu'on en est aux traductions:
Un processeur moderne x86 peut utiliser plus de 4 Gigs de mémoire en utilisant le mode PAE, un mode qui utilise des adresses à 36 bits. En un tel cas un périphérique faisant un transfert direct en mémoire sur un bus à 32 bits ne peut pas accéder à la mémoire au dessus de 4 Gigs. Le nouveau mécanisme de "double cycle d'adressage", s'il est implémenté à la fois sur le bus PCI et dans le périphérique, permet d'adresser sur 64 bits. A défaut, l'OS doit contourner le problème en utilisant de coûteux double "buffers" (nomenclature Windows) ou "bounce buffers" nomenclature Linux.
oui, je ne suis plus vraiment au courant de tout ce qui se fait mais le coût est plus ou moins caché par les différents buffeurs tampon avec ou sans l'on passe pratiquement toujours par une tripotée de buffeurs
(écriture/lecture buffeur temporaire cache l1 l2 l3 etc) ->mémoire ram une seule translation
et le 1 pourcent me paraît assez honnête par contre le double adressage lui est certainement beaucoup plus coûteux en tant que bande passante
La référence 1 est chez Microsoft qui précise tous les problèmes qui se posent si le bus PCI prétend supporter le DAC, sans le supporter en fait. Bref c'est un merdier total quand la chaîne complète, processeur, bus PCI, périphérique ne supporte pas intégralement des adresses à 64 bits.
complètement d'accord je crois bien que sous linux l'on a développé un concept pas trop mal pour les truc transitoire tu prends ta main droite avec les doigts tendus et tu replis l'auriculaire le pouce l'annulaire puis l'index
et là, tu as là un adressage au dessus pour des drivers 32 sur un os 32
Properly written NDIS drivers will work as-is on PAE systems, but will
have a significant negative performance impact that grows as the amount
of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura
un impact négatif significatif sur les performance et qui grandit à
mesure que la quantité de RAM installée augmente.
trop fort Ms
Voici ce que je trouve sur DAC:
http://lwn.net/Articles/28092/
Double address cycle addressing
The PCI bus is capable of a "double address cycle" (DAC) mode of
operation. DAC enables the use of 64-bit DMA addresses, greatly
expanding the range of memory which is reachable on systems without I/O
memory mapping units. DAC is also expensive, however, and is not
properly supported by all devices and buses. So the DMA support routines
will normally go out of their way to avoid creating mappings that
require DAC - even when the driver has set an address mask that would
allow it.
There are occasions where DAC is useful, however. In particular, very
large DMA mappings may not be possible in the normal, single-cycle
address range. For these rare cases, the PCI layer (but not the generic
DMA layer) provides a special set of functions. Note that the DAC
functions can be very expensive to use; they should generally be avoided
unless absolutely necessary. These functions aren't strictly a 2.6
feature; they were also added to 2.4.13.
Donc il y a bien un mécanisme pour que les périphériques puissent faire
des accés DMA en mémoire haute, mais ils sont *onéreux*.
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes
physiques.
De même ici l'article de Wikipedia:
http://en.wikipedia.org/wiki/Direct_memory_access
A modern x86 CPU may use more than 4 GB of memory, utilizing PAE, a
36-bit addressing mode. In such a case, a device using DMA with a 32-bit
address bus is unable to address memory above the 4 GB line. The new
Double Address Cycle (DAC) mechanism, if implemented on both the PCI bus
and the device itself,[1] enables 64-bit DMA addressing. Otherwise, the
operating system would need to work around the problem by using costly
double buffers (Windows nomenclature) also known as bounce buffers
(Linux).
Tant qu'on en est aux traductions:
Un processeur moderne x86 peut utiliser plus de 4 Gigs de mémoire en
utilisant le mode PAE, un mode qui utilise des adresses à 36 bits. En un
tel cas un périphérique faisant un transfert direct en mémoire sur un
bus à 32 bits ne peut pas accéder à la mémoire au dessus de 4 Gigs. Le
nouveau mécanisme de "double cycle d'adressage", s'il est implémenté à
la fois sur le bus PCI et dans le périphérique, permet d'adresser sur 64
bits. A défaut, l'OS doit contourner le problème en utilisant de
coûteux double "buffers" (nomenclature Windows) ou "bounce buffers"
nomenclature Linux.
oui, je ne suis plus vraiment au courant de tout ce qui se fait
mais le coût est plus ou moins caché par les différents buffeurs tampon
avec ou sans l'on passe pratiquement toujours par une tripotée de buffeurs
(écriture/lecture buffeur temporaire cache l1 l2 l3 etc) ->mémoire ram
une seule translation
et le 1 pourcent me paraît assez honnête par contre le double adressage
lui est certainement beaucoup plus coûteux en tant que bande passante
La référence 1 est chez Microsoft qui précise tous les problèmes qui se
posent si le bus PCI prétend supporter le DAC, sans le supporter en
fait. Bref c'est un merdier total quand la chaîne complète, processeur,
bus PCI, périphérique ne supporte pas intégralement des adresses à 64
bits.
complètement d'accord je crois bien que sous linux l'on a développé
un concept pas trop mal pour les truc transitoire
tu prends ta main droite avec les doigts tendus
et tu replis l'auriculaire le pouce l'annulaire puis l'index
et là, tu as là un adressage au dessus pour des drivers 32 sur un os 32
Properly written NDIS drivers will work as-is on PAE systems, but will have a significant negative performance impact that grows as the amount of installed RAM increases.
ce qui donne
Bien écrit pilotes NDIS fonctionnera comme sur PAE-systèmes, mais aura un impact négatif significatif sur les performance et qui grandit à mesure que la quantité de RAM installée augmente.
trop fort Ms
Voici ce que je trouve sur DAC: http://lwn.net/Articles/28092/ Double address cycle addressing The PCI bus is capable of a "double address cycle" (DAC) mode of operation. DAC enables the use of 64-bit DMA addresses, greatly expanding the range of memory which is reachable on systems without I/O memory mapping units. DAC is also expensive, however, and is not properly supported by all devices and buses. So the DMA support routines will normally go out of their way to avoid creating mappings that require DAC - even when the driver has set an address mask that would allow it.
There are occasions where DAC is useful, however. In particular, very large DMA mappings may not be possible in the normal, single-cycle address range. For these rare cases, the PCI layer (but not the generic DMA layer) provides a special set of functions. Note that the DAC functions can be very expensive to use; they should generally be avoided unless absolutely necessary. These functions aren't strictly a 2.6 feature; they were also added to 2.4.13.
Donc il y a bien un mécanisme pour que les périphériques puissent faire des accés DMA en mémoire haute, mais ils sont *onéreux*.
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes physiques.
De même ici l'article de Wikipedia: http://en.wikipedia.org/wiki/Direct_memory_access A modern x86 CPU may use more than 4 GB of memory, utilizing PAE, a 36-bit addressing mode. In such a case, a device using DMA with a 32-bit address bus is unable to address memory above the 4 GB line. The new Double Address Cycle (DAC) mechanism, if implemented on both the PCI bus and the device itself,[1] enables 64-bit DMA addressing. Otherwise, the operating system would need to work around the problem by using costly double buffers (Windows nomenclature) also known as bounce buffers (Linux).
Tant qu'on en est aux traductions:
Un processeur moderne x86 peut utiliser plus de 4 Gigs de mémoire en utilisant le mode PAE, un mode qui utilise des adresses à 36 bits. En un tel cas un périphérique faisant un transfert direct en mémoire sur un bus à 32 bits ne peut pas accéder à la mémoire au dessus de 4 Gigs. Le nouveau mécanisme de "double cycle d'adressage", s'il est implémenté à la fois sur le bus PCI et dans le périphérique, permet d'adresser sur 64 bits. A défaut, l'OS doit contourner le problème en utilisant de coûteux double "buffers" (nomenclature Windows) ou "bounce buffers" nomenclature Linux.
oui, je ne suis plus vraiment au courant de tout ce qui se fait mais le coût est plus ou moins caché par les différents buffeurs tampon avec ou sans l'on passe pratiquement toujours par une tripotée de buffeurs
(écriture/lecture buffeur temporaire cache l1 l2 l3 etc) ->mémoire ram une seule translation
et le 1 pourcent me paraît assez honnête par contre le double adressage lui est certainement beaucoup plus coûteux en tant que bande passante
La référence 1 est chez Microsoft qui précise tous les problèmes qui se posent si le bus PCI prétend supporter le DAC, sans le supporter en fait. Bref c'est un merdier total quand la chaîne complète, processeur, bus PCI, périphérique ne supporte pas intégralement des adresses à 64 bits.
complètement d'accord je crois bien que sous linux l'on a développé un concept pas trop mal pour les truc transitoire tu prends ta main droite avec les doigts tendus et tu replis l'auriculaire le pouce l'annulaire puis l'index
et là, tu as là un adressage au dessus pour des drivers 32 sur un os 32
remy
-- http://remyaumeunier.chez-alice.fr/
Stéphane CARPENTIER
Michel Talon wrote:
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes physiques.
Toi, tu viens de découvrir l'eau chaude.
-- Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Michel Talon wrote:
Moralité, Windows Linux ou autres ne peuvent s'abstraire des contraintes
physiques.
Toi, tu viens de découvrir l'eau chaude.
--
Stéphane
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
