Averelll avait écrit le 18.01.2010 :
> Michel Doucet a écrit :
>> Bonjour/soir, le Mon, 18 Jan 2010 18:38:26 +0100, *Averelll* a caressé son
>> clavier pour nous dire dans le message suivant:
>>
>>>> Je préfère une Dacia qui marche qu'une Porsche bling-bling qui doit
>>>> aller en révision tous les 15 jours ...
>>>>
>>> tellement imbu de votre petite personne que vous passez votre temps à
>>> vouloir imposer votre choix en proférant mensonges et contrevérités.
>>
>> Préférer ne veut pas dire imposer.
>
> C'est pourquoi depuis des années vous ne cessez de troller les groupes
> windows avec mépris et suffisance.
>
> > Imposer c'est ce que MS$ fait avec ces
>> softs troués installés sans le consentement des consommateurs au mépris des
>> lois européennes.
>>
> et c'est reparti avec vos obsessions. Vous êtes un grand malade.
Linux n'est pas le préféré, et il n'arrive pas à s'imposer
Tirer en leçon, Monsieur le Trôleur Obsessionnel
L'étrange chimie qui agite votre cerveau créée des effets propres à
votre personne, vous faisant croire à l'universalité de vos propos, qui
sont, je dois le dire, juste délirants
Avec la lumière du jour, il est préférable d'ouvrir grand les fenêtres
et de vous laisser pénétrer par la lumière salvatrice et réparatrice,
qui dissipera les ombres qui se cachent derrière vous
Le pingouin qui hante vos rêves doit vous quitter au chant du coq,
quitte à le retrouver dès la nuit tombée
Ces quelques heures de répits seront indiscutablement profitables à
tous les deux, et ils vous remercieront chaleureusement
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com
Vinet Raphaël a papoté sur Usenet le janvier 21, 2010 12:57 PM:
Ca va, tu maitrise les symlink ?
Ne venez pas polluer ce forum de votre présence inutile et uniquement trollesque
Au moins s'il avait la capacité mentale d'être un troll, il serait rigolo, ce qui n'est pas du tout le cas.
yjml
In article <hj97fj$2gl5$, Pascal Hambourg writes:
swap, c'est l'inverse du cache puisque le cache est de la RAM contenant des données du disque alors que le swap est du disque contenant des données de la RAM.
(je dis peut-être des conneries merci de rectifier au cas où)
To swap signifie basculer, non ? L'antémémoire des mémoires de masse (cache memory) ou celle du processeur n'évoquent pas la bascule (entre la mémoire de masse et la mémoire vive) de données d'application. C'est un tampon (c'est moins évocateur comme terme). Remy ne devrait pas faire la confusion, ce sont deux fonctionnements différents et incomparable. Avec un swap rapide (1) l'utilisateur a à connaître les tampons et la connaissance de leur fonctionnement peut lui parler, pas le swap, or les machines modernes embarquent beaucoup de RAM.
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une autre page) est beaucoup moins coûteux que le chargement ou l'écriture sur un périphérique lent (disque dur). Sur un processeur à pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse. L'erreur de page est détecté au décodage de l'instruction, alors que les chargement de pages depuis un périphérique lent (plus lent que la RAM le lg se fait sur des milliers d'instructions (quelques dizaines de millisecondes de latence - de quoi vider le pipe-line et introduire un LAG durant lequel le processeur fonctionne sur une seule patte pendant tout le remplissage.
Un effet de bord de la bascule qui peut être désiré est que le thread est suspendu ce qui bloque le processus. ça peut être intéressant de bloquer un processus qui est trop nasty. ça peut aussi être catastrophique si ça enchaine un interblocage...
Plus le disque est lent plus on a intérêt à avoir de RAM, mais il y a toujours un point de rupture au delà duquel la RAM met trop de temps à se remplir. La taille de la RAM «critique» (taille en deça de laquelle on a intérêt à en rajouter) est K*t*f+N0 (t le temps d'accès disque, f la fréquence du processeur, K une cosnstante (le diviseur entre la fréquence du bus et celui du processeur ?) et N0 la taille de mémoire minimum requise (la taille d'un core. Le temps d'accès au disque est une fonction non linéaire de la taille de mémoire paginée) C'est au delà de cette limite qu'on a tout intérêt à partitionner la RAM et le premier emploi utile est le swap (au moins de la taille de l'antémémoire du processeur (le cache level 2 (?)) C'est intéressant d'avoir pour le swap un bloc de la taille de la mémoire utilisée par les applications et le noyau parce que cela permet la mise en veille et le basculement péremptif de tâche. Pour pouvoir « hiberner » il faut se rappeler que la taille du swap (en mémoire de masse) nécessaire est au minimum celui de la mémoire non parti- tionnée (paginée) + celui de la mémoire partitionnée (peut elle être non paginée ?) soit la taille totale de la RAM :)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
In article <hj97fj$2gl5$1@saria.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> writes:
swap, c'est l'inverse du cache puisque le cache est de la RAM
contenant des données du disque alors que le swap est du disque
contenant des données de la RAM.
(je dis peut-être des conneries merci de rectifier au cas où)
To swap signifie basculer, non ? L'antémémoire des mémoires de masse
(cache memory) ou celle du processeur n'évoquent pas la bascule
(entre la mémoire de masse et la mémoire vive) de données d'application.
C'est un tampon (c'est moins évocateur comme terme). Remy ne devrait pas
faire la confusion, ce sont deux fonctionnements différents et
incomparable. Avec un swap rapide (1) l'utilisateur a à connaître
les tampons et la connaissance de leur fonctionnement peut lui parler,
pas le swap, or les machines modernes embarquent beaucoup de RAM.
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une
autre page) est beaucoup moins coûteux que le chargement ou l'écriture
sur un périphérique lent (disque dur).
Sur un processeur à pipeline, ça ne fait un trou que d'une
instruction si je ne m'abuse. L'erreur de page est détecté au
décodage de l'instruction, alors que les chargement de pages
depuis un périphérique lent (plus lent que la RAM le lg se
fait sur des milliers d'instructions (quelques dizaines de
millisecondes de latence - de quoi vider le pipe-line et
introduire un LAG durant lequel le processeur fonctionne
sur une seule patte pendant tout le remplissage.
Un effet de bord de la bascule qui peut être désiré est que le
thread est suspendu ce qui bloque le processus. ça peut être
intéressant de bloquer un processus qui est trop nasty. ça peut
aussi être catastrophique si ça enchaine un interblocage...
Plus le disque est lent plus on a intérêt à avoir de RAM,
mais il y a toujours un point de rupture au delà duquel
la RAM met trop de temps à se remplir. La taille de la RAM
«critique» (taille en deça de laquelle on a intérêt à en rajouter)
est K*t*f+N0 (t le temps d'accès disque, f la fréquence du processeur,
K une cosnstante (le diviseur entre la fréquence du bus et celui du
processeur ?) et N0 la taille de mémoire minimum requise (la taille d'un
core. Le temps d'accès au disque est une fonction non linéaire de la
taille de mémoire paginée) C'est au delà de cette limite qu'on a tout
intérêt à partitionner la RAM et le premier emploi utile est le swap
(au moins de la taille de l'antémémoire du processeur (le cache level 2
(?))
C'est intéressant d'avoir pour le swap un bloc de la taille de la
mémoire utilisée par les applications et le noyau parce que cela permet
la mise en veille et le basculement péremptif de tâche.
Pour pouvoir « hiberner » il faut se rappeler que la taille du swap
(en mémoire de masse) nécessaire est au minimum celui de la mémoire non parti-
tionnée (paginée) + celui de la mémoire partitionnée (peut elle être
non paginée ?) soit la taille totale de la RAM :)
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
swap, c'est l'inverse du cache puisque le cache est de la RAM contenant des données du disque alors que le swap est du disque contenant des données de la RAM.
(je dis peut-être des conneries merci de rectifier au cas où)
To swap signifie basculer, non ? L'antémémoire des mémoires de masse (cache memory) ou celle du processeur n'évoquent pas la bascule (entre la mémoire de masse et la mémoire vive) de données d'application. C'est un tampon (c'est moins évocateur comme terme). Remy ne devrait pas faire la confusion, ce sont deux fonctionnements différents et incomparable. Avec un swap rapide (1) l'utilisateur a à connaître les tampons et la connaissance de leur fonctionnement peut lui parler, pas le swap, or les machines modernes embarquent beaucoup de RAM.
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une autre page) est beaucoup moins coûteux que le chargement ou l'écriture sur un périphérique lent (disque dur). Sur un processeur à pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse. L'erreur de page est détecté au décodage de l'instruction, alors que les chargement de pages depuis un périphérique lent (plus lent que la RAM le lg se fait sur des milliers d'instructions (quelques dizaines de millisecondes de latence - de quoi vider le pipe-line et introduire un LAG durant lequel le processeur fonctionne sur une seule patte pendant tout le remplissage.
Un effet de bord de la bascule qui peut être désiré est que le thread est suspendu ce qui bloque le processus. ça peut être intéressant de bloquer un processus qui est trop nasty. ça peut aussi être catastrophique si ça enchaine un interblocage...
Plus le disque est lent plus on a intérêt à avoir de RAM, mais il y a toujours un point de rupture au delà duquel la RAM met trop de temps à se remplir. La taille de la RAM «critique» (taille en deça de laquelle on a intérêt à en rajouter) est K*t*f+N0 (t le temps d'accès disque, f la fréquence du processeur, K une cosnstante (le diviseur entre la fréquence du bus et celui du processeur ?) et N0 la taille de mémoire minimum requise (la taille d'un core. Le temps d'accès au disque est une fonction non linéaire de la taille de mémoire paginée) C'est au delà de cette limite qu'on a tout intérêt à partitionner la RAM et le premier emploi utile est le swap (au moins de la taille de l'antémémoire du processeur (le cache level 2 (?)) C'est intéressant d'avoir pour le swap un bloc de la taille de la mémoire utilisée par les applications et le noyau parce que cela permet la mise en veille et le basculement péremptif de tâche. Pour pouvoir « hiberner » il faut se rappeler que la taille du swap (en mémoire de masse) nécessaire est au minimum celui de la mémoire non parti- tionnée (paginée) + celui de la mémoire partitionnée (peut elle être non paginée ?) soit la taille totale de la RAM :)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
Toxico Nimbus
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une autre page) est beaucoup moins coûteux que le chargement ou l'écriture sur un périphérique lent (disque dur). Sur un processeur à pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse. L'erreur de page est détecté au décodage de l'instruction, alors que les chargement de pages depuis un périphérique lent (plus lent que la RAM le lg se fait sur des milliers d'instructions (quelques dizaines de millisecondes de latence - de quoi vider le pipe-line et introduire un LAG durant lequel le processeur fonctionne sur une seule patte pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un passage en mode privilégié, donc un contexte-switch avec vidage de pipe- line mais aussi sauvegarde/restauration de contexte de vidage de cache (en partie). Au milieu de tout ça, la vidage du pipe-line est négligeable.
Un effet de bord de la bascule qui peut être désiré est que le thread est suspendu ce qui bloque le processus. ça peut être intéressant de bloquer un processus qui est trop nasty. ça peut aussi être catastrophique si ça enchaine un interblocage...
Comment (ou pourquoi) peut-on désirer suspendre un thread de cette manière, sachant que l'accès disque + contexte-switch est plus préjudiciable au système que n'importe quoi d'autre ? Si c'est le cas il y a un défaut de conception au niveau de la gestion des tâches (affectation des priorités, manque de time-slice...)
-- Toxico Nimbus
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans
une autre page) est beaucoup moins coûteux que le chargement ou
l'écriture sur un périphérique lent (disque dur). Sur un processeur à
pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse.
L'erreur de page est détecté au décodage de l'instruction, alors que les
chargement de pages depuis un périphérique lent (plus lent que la RAM le
lg se fait sur des milliers d'instructions (quelques dizaines de
millisecondes de latence - de quoi vider le pipe-line et introduire un
LAG durant lequel le processeur fonctionne sur une seule patte pendant
tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un
passage en mode privilégié, donc un contexte-switch avec vidage de pipe-
line mais aussi sauvegarde/restauration de contexte de vidage de cache
(en partie). Au milieu de tout ça, la vidage du pipe-line est négligeable.
Un effet de bord de la bascule qui peut être désiré est que le thread
est suspendu ce qui bloque le processus. ça peut être intéressant de
bloquer un processus qui est trop nasty. ça peut aussi être
catastrophique si ça enchaine un interblocage...
Comment (ou pourquoi) peut-on désirer suspendre un thread de cette
manière, sachant que l'accès disque + contexte-switch est plus
préjudiciable au système que n'importe quoi d'autre ? Si c'est le cas il
y a un défaut de conception au niveau de la gestion des tâches
(affectation des priorités, manque de time-slice...)
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une autre page) est beaucoup moins coûteux que le chargement ou l'écriture sur un périphérique lent (disque dur). Sur un processeur à pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse. L'erreur de page est détecté au décodage de l'instruction, alors que les chargement de pages depuis un périphérique lent (plus lent que la RAM le lg se fait sur des milliers d'instructions (quelques dizaines de millisecondes de latence - de quoi vider le pipe-line et introduire un LAG durant lequel le processeur fonctionne sur une seule patte pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un passage en mode privilégié, donc un contexte-switch avec vidage de pipe- line mais aussi sauvegarde/restauration de contexte de vidage de cache (en partie). Au milieu de tout ça, la vidage du pipe-line est négligeable.
Un effet de bord de la bascule qui peut être désiré est que le thread est suspendu ce qui bloque le processus. ça peut être intéressant de bloquer un processus qui est trop nasty. ça peut aussi être catastrophique si ça enchaine un interblocage...
Comment (ou pourquoi) peut-on désirer suspendre un thread de cette manière, sachant que l'accès disque + contexte-switch est plus préjudiciable au système que n'importe quoi d'autre ? Si c'est le cas il y a un défaut de conception au niveau de la gestion des tâches (affectation des priorités, manque de time-slice...)
-- Toxico Nimbus
JKB
Le 22-01-2010, ? propos de Re: swap en RAM (anciennement : Lettre à M.D., Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une autre page) est beaucoup moins coûteux que le chargement ou l'écriture sur un périphérique lent (disque dur). Sur un processeur à pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse. L'erreur de page est détecté au décodage de l'instruction, alors que les chargement de pages depuis un périphérique lent (plus lent que la RAM le lg se fait sur des milliers d'instructions (quelques dizaines de millisecondes de latence - de quoi vider le pipe-line et introduire un LAG durant lequel le processeur fonctionne sur une seule patte pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un passage en mode privilégié, donc un contexte-switch avec vidage de pipe- line mais aussi sauvegarde/restauration de contexte de vidage de cache (en partie). Au milieu de tout ça, la vidage du pipe-line est négligeable.
Vidage de pipe-line ? Je ne vois pas pourquoi. Enfin, si, sur un x86, je vois, mais dans le cas général de processeur bien fichu, c'est faux. Je rajouterais même que le pipe-line sur un processeur CISC est une aberration. Il se casse la gueule entre deux instructions, une fois sur deux à chaque saut et j'en passe. Vouloir mettre un pipe-line efficace sur un CISC, c'est une gagueure. C'est principalement pour ça que les x86 sont maintenant en interne des RISC, mais ça ne résout de loin pas tout. Pour avoir un pipe-line efficace, il faut que toutes les instructions fassent la même longueur et surtout qu'elles soient toutes exécutées en un même nombre de cycle, ce qui est très difficile à faire sur un CISC en raison des nombreux modes d'adressages et des binaires existants. Pour charger une valeur de 32 bits sur un sparc, il faut _deux_ instructions, l'une pour charger les 22 bits de poids forts et l'autre pour les 10 bits restants. Comment faire sinon pour ne pas voir le pipe-line se casser la gueule ? Il faut que les instructions soient toutes de 32 bits et exécutées en un même nombre de cycle... Avec les chargements des x86, on est déjà dans la mouise ;-)
Idem pour les changements de contextes et les empilages de registres. Par contre, la décohérence de cache est _le_ problème principal. C'est même pour ça que les vrais processeurs qui dont destinés à des utilisations dans des architectures à temps partagé (comprendre, autre chose que le x86 gonflé) ont un peu plus d'un Mo de cache même à des vitesses faibles (8 Mo pour un U-III qui tourne à 900 MHz, 2 Mo pour un ev56/500, 1 à 2 Mo pour un SS-II à... 75 MHz ! J'ai même une SparcStation 2 estampillé MentorGraphic avec 1 Mo de cache pour un processeur Sparc V7 qui tourne à la redoutable vitesse de... 40 MHz !).
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 22-01-2010, ? propos de
Re: swap en RAM (anciennement : Lettre à M.D.,
Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans
une autre page) est beaucoup moins coûteux que le chargement ou
l'écriture sur un périphérique lent (disque dur). Sur un processeur à
pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse.
L'erreur de page est détecté au décodage de l'instruction, alors que les
chargement de pages depuis un périphérique lent (plus lent que la RAM le
lg se fait sur des milliers d'instructions (quelques dizaines de
millisecondes de latence - de quoi vider le pipe-line et introduire un
LAG durant lequel le processeur fonctionne sur une seule patte pendant
tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un
passage en mode privilégié, donc un contexte-switch avec vidage de pipe-
line mais aussi sauvegarde/restauration de contexte de vidage de cache
(en partie). Au milieu de tout ça, la vidage du pipe-line est négligeable.
Vidage de pipe-line ? Je ne vois pas pourquoi. Enfin, si, sur un
x86, je vois, mais dans le cas général de processeur bien fichu,
c'est faux. Je rajouterais même que le pipe-line sur un processeur
CISC est une aberration. Il se casse la gueule entre deux
instructions, une fois sur deux à chaque saut et j'en passe.
Vouloir mettre un pipe-line efficace sur un CISC, c'est une gagueure.
C'est principalement pour ça que les x86 sont maintenant en interne
des RISC, mais ça ne résout de loin pas tout. Pour avoir un
pipe-line efficace, il faut que toutes les instructions fassent la
même longueur et surtout qu'elles soient toutes exécutées en un même
nombre de cycle, ce qui est très difficile à faire sur un CISC en
raison des nombreux modes d'adressages et des binaires existants.
Pour charger une valeur de 32 bits sur un sparc, il faut _deux_
instructions, l'une pour charger les 22 bits de poids forts et
l'autre pour les 10 bits restants. Comment faire sinon pour ne pas
voir le pipe-line se casser la gueule ? Il faut que les instructions
soient toutes de 32 bits et exécutées en un même nombre de cycle...
Avec les chargements des x86, on est déjà dans la mouise ;-)
Idem pour les changements de contextes et les empilages
de registres. Par contre, la décohérence de cache est _le_ problème
principal. C'est même pour ça que les vrais processeurs qui dont
destinés à des utilisations dans des architectures à temps partagé
(comprendre, autre chose que le x86 gonflé) ont un peu plus d'un Mo
de cache même à des vitesses faibles (8 Mo pour un U-III qui tourne à
900 MHz, 2 Mo pour un ev56/500, 1 à 2 Mo pour un SS-II à... 75 MHz !
J'ai même une SparcStation 2 estampillé MentorGraphic avec 1 Mo de
cache pour un processeur Sparc V7 qui tourne à la redoutable vitesse
de... 40 MHz !).
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 22-01-2010, ? propos de Re: swap en RAM (anciennement : Lettre à M.D., Toxico Nimbus ?crivait dans fr.comp.os.linux.configuration :
Le Fri, 22 Jan 2010 01:56:51 +0000, Yves Lambert a écrit :
(1) Le chargement d'une page mémoire ou sa recopie à l'identique dans une autre page) est beaucoup moins coûteux que le chargement ou l'écriture sur un périphérique lent (disque dur). Sur un processeur à pipeline, ça ne fait un trou que d'une instruction si je ne m'abuse. L'erreur de page est détecté au décodage de l'instruction, alors que les chargement de pages depuis un périphérique lent (plus lent que la RAM le lg se fait sur des milliers d'instructions (quelques dizaines de millisecondes de latence - de quoi vider le pipe-line et introduire un LAG durant lequel le processeur fonctionne sur une seule patte pendant tout le remplissage.
En même temps, l'exeption défaut de page provoque nécessairement un passage en mode privilégié, donc un contexte-switch avec vidage de pipe- line mais aussi sauvegarde/restauration de contexte de vidage de cache (en partie). Au milieu de tout ça, la vidage du pipe-line est négligeable.
Vidage de pipe-line ? Je ne vois pas pourquoi. Enfin, si, sur un x86, je vois, mais dans le cas général de processeur bien fichu, c'est faux. Je rajouterais même que le pipe-line sur un processeur CISC est une aberration. Il se casse la gueule entre deux instructions, une fois sur deux à chaque saut et j'en passe. Vouloir mettre un pipe-line efficace sur un CISC, c'est une gagueure. C'est principalement pour ça que les x86 sont maintenant en interne des RISC, mais ça ne résout de loin pas tout. Pour avoir un pipe-line efficace, il faut que toutes les instructions fassent la même longueur et surtout qu'elles soient toutes exécutées en un même nombre de cycle, ce qui est très difficile à faire sur un CISC en raison des nombreux modes d'adressages et des binaires existants. Pour charger une valeur de 32 bits sur un sparc, il faut _deux_ instructions, l'une pour charger les 22 bits de poids forts et l'autre pour les 10 bits restants. Comment faire sinon pour ne pas voir le pipe-line se casser la gueule ? Il faut que les instructions soient toutes de 32 bits et exécutées en un même nombre de cycle... Avec les chargements des x86, on est déjà dans la mouise ;-)
Idem pour les changements de contextes et les empilages de registres. Par contre, la décohérence de cache est _le_ problème principal. C'est même pour ça que les vrais processeurs qui dont destinés à des utilisations dans des architectures à temps partagé (comprendre, autre chose que le x86 gonflé) ont un peu plus d'un Mo de cache même à des vitesses faibles (8 Mo pour un U-III qui tourne à 900 MHz, 2 Mo pour un ev56/500, 1 à 2 Mo pour un SS-II à... 75 MHz ! J'ai même une SparcStation 2 estampillé MentorGraphic avec 1 Mo de cache pour un processeur Sparc V7 qui tourne à la redoutable vitesse de... 40 MHz !).
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
Yves Lambert wrote in message <4b5905e3$0$5898$:
To swap signifie basculer, non ?
Échanger, plutôt, en anglais moderne. Mais c'est oiseux : le sens d'un mot dans un domaine technique ne peut pas se déduire de son sens courant.
Yves Lambert wrote in message <4b5905e3$0$5898$426a74cc@news.free.fr>:
To swap signifie basculer, non ?
Échanger, plutôt, en anglais moderne. Mais c'est oiseux : le sens d'un mot
dans un domaine technique ne peut pas se déduire de son sens courant.
Échanger, plutôt, en anglais moderne. Mais c'est oiseux : le sens d'un mot dans un domaine technique ne peut pas se déduire de son sens courant.
moi-meme
Le Thu, 21 Jan 2010 08:39:34 +0000, Kevin Denis a écrit :
Je pense que le coût d'une I/O est prohibitif. Comprimer le swap sur disque, cela reviendrait à écrire une (ou un petit nombre) de page sur le disque au lieu d'en écrire plusieurs. Dans tout les cas, il faut écrire. La différence de coût d'écriture entre une et plusieurs pages doit être faible. Tout du moins, en regard d'une I/O.
Quand on utilise le swap c'est qu'il n'y a plus de mémoire. Comprimer le swap veut dire prendre encore de la mémoire alors qu'on n'en a plus. Donc c'est idiot de vouloir compresser dans ce cas.
J'ai faux ?
Le Thu, 21 Jan 2010 08:39:34 +0000, Kevin Denis a écrit :
Je pense que le coût d'une I/O est prohibitif. Comprimer le swap sur
disque, cela reviendrait à écrire une (ou un petit nombre) de page sur
le disque au lieu d'en écrire plusieurs. Dans tout les cas, il faut
écrire.
La différence de coût d'écriture entre une et plusieurs pages doit être
faible. Tout du moins, en regard d'une I/O.
Quand on utilise le swap c'est qu'il n'y a plus de mémoire.
Comprimer le swap veut dire prendre encore de la mémoire alors qu'on
n'en a plus.
Donc c'est idiot de vouloir compresser dans ce cas.
Le Thu, 21 Jan 2010 08:39:34 +0000, Kevin Denis a écrit :
Je pense que le coût d'une I/O est prohibitif. Comprimer le swap sur disque, cela reviendrait à écrire une (ou un petit nombre) de page sur le disque au lieu d'en écrire plusieurs. Dans tout les cas, il faut écrire. La différence de coût d'écriture entre une et plusieurs pages doit être faible. Tout du moins, en regard d'une I/O.
Quand on utilise le swap c'est qu'il n'y a plus de mémoire. Comprimer le swap veut dire prendre encore de la mémoire alors qu'on n'en a plus. Donc c'est idiot de vouloir compresser dans ce cas.
J'ai faux ?
Nicolas George
moi-meme wrote in message <4b59b41a$0$24828$:
Comprimer le swap veut dire prendre encore de la mémoire
Ça veut dire prendre n pages pour y stocker p pages, avec p > n, donc libérer p - n pages. Ça peut être particulièrement intéressant pour un truc de dessins avec beaucoup de layers blancs, par exemple.
alors qu'on n'en a plus.
Il faut forcément un peu d'espace temporaire pour effectuer la compression, mais très peu, et une quantité constante.
moi-meme wrote in message <4b59b41a$0$24828$426a74cc@news.free.fr>:
Comprimer le swap veut dire prendre encore de la mémoire
Ça veut dire prendre n pages pour y stocker p pages, avec p > n, donc
libérer p - n pages. Ça peut être particulièrement intéressant pour un truc
de dessins avec beaucoup de layers blancs, par exemple.
alors qu'on
n'en a plus.
Il faut forcément un peu d'espace temporaire pour effectuer la compression,
mais très peu, et une quantité constante.
Comprimer le swap veut dire prendre encore de la mémoire
Ça veut dire prendre n pages pour y stocker p pages, avec p > n, donc libérer p - n pages. Ça peut être particulièrement intéressant pour un truc de dessins avec beaucoup de layers blancs, par exemple.
alors qu'on n'en a plus.
Il faut forcément un peu d'espace temporaire pour effectuer la compression, mais très peu, et une quantité constante.
NiKo
P4nd1-P4nd4 a écrit :
Ca va, tu maitrise les symlink ?
T'as pas assez d'FCOLD pour ramener ton inculture ? Tu te fais pas assez traiter de gros con là bas, tu en demandes encore ?
P4nd1-P4nd4 a écrit :
Ca va, tu maitrise les symlink ?
T'as pas assez d'FCOLD pour ramener ton inculture ?
Tu te fais pas assez traiter de gros con là bas, tu en demandes encore ?
T'as pas assez d'FCOLD pour ramener ton inculture ?
Il a suivi un fu2. Probablement sans s'en rendre compte.
moi-meme
Le Fri, 22 Jan 2010 15:27:01 +0100, Franssoa a écrit :
Quand on utilise le swap c'est qu'il n'y a plus de mémoire. Comprimer le swap veut dire prendre encore de la mémoire alors qu'on n'en a plus. Donc c'est idiot de vouloir compresser dans ce cas.
La solution : http://www.downloadmoreram.com/ :-)
Franssoa
j'ai téléchargé 1G : on sent le changement.
T'as pas une adresse pour télécharger une imprimante ?
Le Fri, 22 Jan 2010 15:27:01 +0100, Franssoa a écrit :
Quand on utilise le swap c'est qu'il n'y a plus de mémoire. Comprimer
le swap veut dire prendre encore de la mémoire alors qu'on n'en a
plus.
Donc c'est idiot de vouloir compresser dans ce cas.
La solution : http://www.downloadmoreram.com/ :-)
Franssoa
j'ai téléchargé 1G : on sent le changement.
T'as pas une adresse pour télécharger une imprimante ?
Le Fri, 22 Jan 2010 15:27:01 +0100, Franssoa a écrit :
Quand on utilise le swap c'est qu'il n'y a plus de mémoire. Comprimer le swap veut dire prendre encore de la mémoire alors qu'on n'en a plus. Donc c'est idiot de vouloir compresser dans ce cas.
La solution : http://www.downloadmoreram.com/ :-)
Franssoa
j'ai téléchargé 1G : on sent le changement.
T'as pas une adresse pour télécharger une imprimante ?
