Intérêt du cache 8Mo [Ca ne sert à rien (?), benchmark inside]

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 3 4 5 6 7 8 9 10 11 12 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Intérêt du cache 8Mo [Ca ne sert à rien (?), benchmark inside]

glacote

Reprise du message précédent :

muzah a écrit :

sans doute ; en plus on sait pertinement que même NT ne s'octroie pas le droit d'accéder directement au matériel (heureusement dirotn certains )

Enfin bref.

C'est vrai ça ? Je croyais qu'il squizzait le bios (mais je peux me tromper) ... En tout cas Linux se moque complètement du bios à ma connaissance (faillible encore une fois).

Publicité

glacote

benj9002 a écrit :

Il faut aussi faire le matériel en fonction de ce que l'OS sait faire Si ton OS ne gère pas directement le matériel, ton idée de cache en RAM ne tiens plus [:spamafote]

OK je suis d'accord. Mais je crois que les OS actuels ont une connaissance suffisante du matériel : i.e. ils savent adresser les disques en LBA et faire des requêtes de transfert DMA du disque vers la RAM (en tout cas Linux 2.4 sait faire).

blazkowicz

l'OS met en cache au niveau du système de fichier non?

il ya quelque différence entre NFTS/FAT et l'adressage LBA : une couche d'abstraction en plus

je ne crois pas qu'un OS comme windaube ou unix puisse faire un cache de si "bas niveau"?

Message édité par blazkowicz le 01-07-2003 à 22:22:52

mrbebert

Message édité par mrbebert le 01-07-2003 à 22:26:18

glacote

Blazkowicz a écrit :

Bon là c'est un peu de ma faute, j'ai lancé un topic sans aller relire les sources de mon kernel ... :spamafote
Mais je crois bien que l'OS fait du cache au niveau des secteurs à aller chercher, pas au niveau des clusters de la partition. Mais je peux me tromper.

PS: quitte à rajouter une étape de LVM (la couche d'abstraction qu'on utilise quand on fait du RAID, mais qu'on peut utiliser seule), là c'est sûr que tu caches au niveau des secteurs LVM, donc des secteurs physiques. Par contre là la taille du tampon est fixe et << 300Mo (?).

glacote

mrBebert a écrit :

Pourtant, l'OS a des avantages énormes sur le disque :
- il connait l'organisation des fichiers. Si un fichier est fragmenté, l'OS le sait et connait le secteur suivant, pas le disque
> +1

- il a une vue générale sur tous les programmes, si certains fichiers sont utilisés par plusieurs programmes
> +1
D'ailleurs si tu utilises le prelink (c'est le truc sous Linux qui permet de "préparer" les exécutables pour que la liaison dynamique avec les DLL (les .so sous Unix) se fasse toujours à la même adresse, donc plus vite), si j'ai bien compris comment ça marche tu facilites encore les accès au disque (la lib à charger est en fait "intégrée" à l'exécutable, pas besoin d'aller la chercher ailleurs sur le disque).

Blazkowicz > si, l'OS connait l'adresse sur le disque de chaque fichier (de chaque secteur). C''est lui qui fait le lien entre les 2 (d'ailleurs, c'est lui qui défragmente)
> Je suis d'accord, mais encore faudrait-il vérifier qu'il va vraiment s'en servir. Bon il va falloir faire un post sur OSA ...
EDIT:
http://forum.hardware.fr/forum2.ph [...] h=&subcat=

Message édité par glacote le 01-07-2003 à 22:41:40

skeye

glacote a écrit :

Le prelink c'est plutot que les libs nécéssaires à l'appli seront chargées à l'avance...

glacote

skeye a écrit :

Le prelink c'est plutot que les libs nécéssaires à l'appli seront chargées à l'avance...

Donc dans ce cas il faudra bien aller les chercher là où elles sont, puis aller chercher l'exécutable. Donc ça n'améliore pas les accès disques. Autant pour moi.

Eric B

le cache des disques durs, c'est de la sdram classique ou c'est de la sram ?

muzah

Bal Musette @ HFR depuis 1997

je n'en ai aucune idée, il faudrait aller voir sur les sites spécialisés parce que là je sèche :sweat:

Publicité

glacote

Mahieu a écrit :

oui mais si tu as 133Mo/Sec sur le PCI et que tu en bouffes déjà 50Mo/sec (tu tires ça d'où dailleurs? lkes dernier DD font bien plus de 50Mo/sec...), il en reste d'autant moins pour tout le reste: réseau etc....

1) Je croyais que même les meilleurs 7200t/min ne dépassaient pas les 50Mo/s ne lecture
http://www.hardware.fr/articles/414/page4.html
mais bon peut-être que je me trompe ...
2) pour les autres composants PCI, cf les autres posts.
En revanche oui, si plus de deux disques moulinent simultanément le PCI est mort.
Vive le PCI-X ...

popoles

glacote a écrit :

1) Je croyais que même les meilleurs 7200t/min ne dépassaient pas les 50Mo/s ne lecturehttp://www.hardware.fr/articles/414/page4.html
mais bon peut-être que je me trompe ...
2) pour les autres composants PCI, cf les autres posts.
En revanche oui, si plus de deux disques moulinent simultanément le PCI est mort.
Vive le PCI-X ...

vers 60 Mo/s actuellement

skeye

glacote a écrit :

Il faut pas oublier qu'un serveur de fichier sérieux sera en RAID...si c'est que du mirroring ca change pas grand-chose, c'est le controleur RAID qui prend tout dans la gueule, mais sinon (RAID 5, au hasard, qui fait quand même plus sérieux!), le pci risque fort de très vite souffrir lors des accès disque!

glacote

skeye a écrit :

Oui je suis d'accord. Pire encore, si tu fais tu RAID software (puisqu'on parle d'économiser 15 Euros par disque, on ne va pas non plus acheter un contrôleur RAID à 33 Euros), dans tous les cas tu sature le bus. Sauf avec seulement deux disques.
cf http://www6.tomshardware.com/stora [...] up-03.html

Message édité par glacote le 02-07-2003 à 10:01:11

glacote

(:bounce

chips-disqueman

apt-get update

glacote a écrit :

33 ? un contrôleur RAID ? Il doit pas faire du raid5 à ce prix-là...

glacote

chips-disqueman a écrit :

33 ? un contrôleur RAID ? Il doit pas faire du raid5 à ce prix-là...

Euh non, 35? c'est le "de base" avec deux nappes et RAID 0,1 ou 0+1 (4 disques).
La carte RAID-5 avec contrôleur RISC intégré et cache, c'est plutôt 250? ...

chips-disqueman

apt-get update

glacote a écrit :

Euh non, 35? c'est le "de base" avec deux nappes et RAID 0,1 ou 0+1 (4 disques).
La carte RAID-5 avec contrôleur RISC intégré et cache, c'est plutôt 250? ...

Surtout que ces modèles-là sont SCSI en général. (ça existe un contrôleur raid 5 ide ? :lol: )

skeye

glacote a écrit :

Euh non, 35? c'est le "de base" avec deux nappes et RAID 0,1 ou 0+1 (4 disques).
La carte RAID-5 avec contrôleur RISC intégré et cache, c'est plutôt 250? ...

Tu le trouves où à ce prix? :whistle:

nurgle

le raid5 IDE existe (chez adaptec)

pour les 133 Mo/sec pour le cache, vous oubliez que tout les gens qui ont un chipset Intel (pas mal de monde, donc) sont limités a l'ATA100, donc 100Mo/sec et pas 133.

de plus le PCI commence a etre saturé sur un config de base.

réseau :
2*12.5 Mo/sec.
son :
je sais pas exactement, mais c'est pas négligeable comme certains le croit (j'ai lu un article il y a quelque mois selon lequelle un des avantages du nforce, c'est que le son passe par l'Hypertransport et libère donc le PCI)
modem ADSL/56K :
1 Mo/sec, on va etre gentil
carte TV et hypothétique carte graphique PCI : ?

en fait je dis ca parce que je vois la différence sur mon PC si il y a bcp sur le PCI (6 cartes, USB2, Cartegraphique, réseau, modem adsl, TV et son) et quand je mets rien (pour du test).

de plus chez via par exemple, le PCI n'est pas efficace a 100% (c'est plus pres de 110 Mo/sec que de 133).

mais je ne sais toujours pas pourquoi le cache augmente tant les performances en utilisation avancée.

sinon, tant qu'on parle un peu de scsi aussi, les disques scsi ont plus de cache au départ parce que a mécanique totalement identique, un disque scsi a un temps d'acces moins bon qu'un disque IDE, vu que la latence du a l'électronique suplémentaire est la, et le cache compense ca (c'est de l'ordre de 1/2 a 1ms)

glacote

skeye a écrit :

Tu le trouves où à ce prix? :whistle:

Facile :
http://www.adaptec.com/worldwide/p [...] R-2400A_FR
c'est ... euh ... 445 Euros (désolé) !

skeye

glacote a écrit :

Facile :
http://www.adaptec.com/worldwide/p [...] R-2400A_FR
c'est ... euh ... 445 Euros (désolé) !

Je parlais de celle à 35? pour le RAID 0+1... :whistle:

glacote

nurgle a écrit :

> Bah pour le son, je me suis peut-être trompé. Si on prend pour principe que ça n'est pas au-delà de 3* la qualité CD (5.1 au lieu de stéréo) on en est à 0.9Mo/s ... mais c'est "à la louche".

nurgle a écrit :

en fait je dis ca parce que je vois la différence sur mon PC si il y a bcp sur le PCI (6 cartes, USB2, Cartegraphique, réseau, modem adsl, TV et son) et quand je mets rien (pour du test).

de plus chez via par exemple, le PCI n'est pas efficace a 100% (c'est plus pres de 110 Mo/sec que de 133).

Certes, mais bon le PCI reste toujours au-dessus des 110Mo/s ...

nurgle a écrit :

mais je ne sais toujours pas pourquoi le cache augmente tant les performances en utilisation avancée.

Voilà une question à laquelle j'aimerais avoir une réponse ...

nurgle a écrit :

sinon, tant qu'on parle un peu de scsi aussi, les disques scsi ont plus de cache au départ parce que a mécanique totalement identique, un disque scsi a un temps d'acces moins bon qu'un disque IDE, vu que la latence du a l'électronique suplémentaire est la, et le cache compense ca (c'est de l'ordre de 1/2 a 1ms)

C'est vrai, mais d'un autre côté en général on achète des Cheetah 15000 rpm, pas des 7200 rpm ...

glacote

skeye a écrit :

Je parlais de celle à 35? pour le RAID 0+1... :whistle:

Promise Ultra 100 à 35? : http://www.rue-montgallet.com/prix/details/2956/
Test : http://www.gamepc.com/labs/view_co [...] e%5Ftest=1
Cela dit à mon avis le RAID 0+1 c'est complètement débile. Pour ce qui me concerne, je vais sans doute acheter cette carte mais pour faire du RAID 5 en software avec 3 disques et pas 4.

janus_75

nurgle a écrit :

tu peux nous indiquer où tu as trouvé cette information ? celà m'interresse... :jap:

glacote

Pour ceux qui s'ennuient, voilà comment marchent les entrées-sorties sous Linux :
http://www-2.cs.cmu.edu/~mukesh/hacks/spindown/t1.html
Sous Linux, il y a une couche intermédiaire entre système de fichiers et périphérique : c'est le Virtual File System. Celui-ci maintient deux caches : le buffer cache,
sous forme d'une liste chaînée (avec double accès par table de hashage pour l'efficacité) des secteurs tamponnés.
Lors de chaque lecture, la fonction [tt]getblk[/tt] commence par vérifier que les données ne se trouvent pas en cache, avant de générer une requête de lecture sur le périphérique.
Le page cache, lui, tamponne des pages (ie des morceaux de 4ko) de fichiers ouverts.
Source: http://www.kernelhacking.org/docs/ [...] exs03.html
Conclusion : Linux est à la fois capable d'optimiser au niveau des clusters (via le page cache, en chargeant par anticipation les prochains clusters du fichier en cours) et au niveau des secteurs (via le buffer cache). Trop fort, ce petit Linux ...

Message édité par glacote le 02-07-2003 à 16:50:52

nurgle

janus_75 a écrit :

tu peux nous indiquer où tu as trouvé cette information ? celà m'interresse... :jap:

macmillan le PC.

Ils comparait un 18Go IBM 7200rpm, et le modèle IDE allait + vite que le scsi, mais ils insistait que le scsi était un bas de gamme et l'IDE un haut de gamme.

d'ailleurs un truc bizarre, c'est que un disque pata sur un controlleur sata avec adaptateur ne perde pas en perfs, c'est pas logique.

et je pense que quand le sata sera généralisé, on verra encore plus la différence entre les 8Mo et les 2Mo de cache (vu que le disque ne partagera pas le bus et aura 150Mo/sec de BP).

Message édité par nurgle le 02-07-2003 à 17:04:50

glacote

La fameuse fonction getblk, as of kernel 2.4.21

Code :

struct buffer_head * getblk(kdev_t dev, int block, int size)
{
for (;;) {
struct buffer_head * bh;
bh = get_hash_table(dev, block, size);
if (bh) {
touch_buffer(bh);
return bh;
}
if (!grow_buffers(dev, block, size))
free_more_memory();
}
}

Reste à savoir ce que fait "grow_buffers"

Code :

/*
* Try to increase the number of buffers available: the size argument
* is used to determine what kind of buffers we want.
*/
static int grow_buffers(kdev_t dev, unsigned long block, int size)
{ ...
/* Create a page with the proper size buffers.. */
page = grow_dev_page(bdev, index, size);
...
}

Code :

/*
* Create the page-cache page that contains the requested block
*/
static struct page * grow_dev_page(struct block_device *bdev, unsigned long index, int size)
{
...
page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
...
bh = create_buffers(page, size, 0);
...
link_dev_buffers(page, bh);
...
}

Hope it helps ...

glacote

Précision:

Code :

static void free_more_memory(void)
{
balance_dirty();
wakeup_bdflush();
try_to_free_pages(GFP_NOIO);
yield();
}

donc le page cache est en compétition avec tous les autres processus pour obtenir des pages de mémoire, sans discrimination (et sans limite non plus: s'il reste de la RAM, il la prend).

Par ailleurs, sous Linux, il y a un thread à part (bdflush) en charge d'écrire les pages modifiées dans le tampon sur le disque. [tt]wakeup_bdflush()[/tt] dit à ce thread de s'activer un peu, et le [tt]yield()[/tt] rend finalement la main au système.

En particulier, le page cache cherche d'abord à vider ses pages modifées et non réécrites sur disque avant de chercher à s'accaparer un peu plus de RAM (try_to_free_pages s'adresse aux autres processus qui utilisent de la mémoire).

La question en suspens est : est-ce qu'un autre processus peu appeler [tt]free_more_memory[/tt], forçant ainsi le cache disque à vider son cache (et à libérer de la RAM) ? Je ne suis pas sûr mais je ne crois pas vu que ce n'est pas un symbole exporté.

Message édité par glacote le 02-07-2003 à 17:46:07

lalrobin

glacote a écrit :

OK.
Mais comme je l'ai déjà dit, après avoir lancé ma Mandrake 9.1, les disques finissent par s'arrêter même si j'ouvre une nouvelle fenêtre Mozilla/un nouveau document OpenOffice.
Les bibliothèques/artworks/etc nécessaires sont dans le cache de l'OS (jusqu'à 650 Mo) et il n'y a aucun accès disque. En d'autres termes avec un gros cache les accès de l'OS au disque sont rares, et il y a peu de chances que lorsque l'OS fait sa requête les têtes soient en cours de positionnement.

Petit rappel.

Tes exemples est tres mauvais.
Tu es dans un cas ou l'OS n a pas besoin du tout du DD.
Qd tu ouve une nouvelle fenetre Mozzila, il fait un fork. Il fait une copie du processus qui tourne(RAM,environement etc...) avec une relation pere fils. Mais dans aucun cas il doit ecrire quelque chose dans le DD. Mozilla est alncé en memoire, il n'a que a dupliquer ce process deja lancé.
Qd tu ouvre un nouveau doc, tu croit qu'il ecrit sur le DD? pourquoi il le ferai? Il a de la ram plus rapide à sa disposition. Il n'ecrira que si tu force la sauvegarde sur le DD.

Dans aucun cas tu utilise le cache de l'OS dans ton premier cas du fais un duplication de process deja lancer et donc ca n a rien avoir avec une lecture dans le cache d'un exe ou autre...
Dans le deuxieme cas, ce n est pas le cache de l'OS qui joue. Dans le code pour optimiser les acces disque.
Les developpeur ont choisi de charger en memoire le document ouvert. Il aurait pu choisir d'ecrire direct sur le DD un fichier et ton cache OS ne servirait à rien...

lalrobin

janus_75 a écrit :

l'intérêt du cache disque est :
- lecture en avance de demande (donc l'OS ne l'a pas encore en cache puisqu'il ne l'a pas encore demandé )
- écriture différée (le disque répond que l'écriture est ok alors qu'elle uniquement copiée dans le cache du disque). Ceci permet une meilleure gestion des entrées/sorties en multi-taches. En revanche je ne suis pas sur que l'interface IDE ne limite pas justement cet aspect des choses contrairement au disques SCSI...
- gestion et réorganisation des lectures/écritures à la volée (applicable surtout en SCSI).
- l'OS ne connait pas du tout la structure physique réelle du disque. Seul le firmware du disque la connait. Donc le cache disque permet de cacher plus efficacement puisque seul le disque sait réellement où la donnée va être écrite.

Pour moi, je ne pense pas que la différence entre 2 Mo et 8 Mo sera sensible en environnement mono-poste. En serveur multi-utilisateurs c'est autre chose...

chips-disqueman

apt-get update

glacote a écrit :

Précision:

Code :

static void free_more_memory(void)
{
balance_dirty();
wakeup_bdflush();
try_to_free_pages(GFP_NOIO);
yield();
}

Eh bé ! :jap: Mais là j'y comprends plus rien... Vivement les prochaines années !

glacote

lalrobin a écrit :

Oui tu as raison. Il faudrait comparer plutôt le temps du deuxième lancement d'une même application, avec 2Mo d'une part et avec 8Mo d'autre part, toutes choses égales par ailleurs.
Qui se dévoue ?

glacote

chips-disqueman a écrit :

Eh bé ! :jap: Mais là j'y comprends plus rien... Vivement les prochaines années !

Bah je n'ai pas écrit ça pour faire mon malin, mais dans l'espoir qu'un hacker compétent saurait orienter la discussion ...

mrbebert

glacote a écrit :

...
Par ailleurs, sous Linux, il y a un thread à part (bdflush) en charge d'écrire les pages modifiées dans le tampon sur le disque. [tt]wakeup_bdflush()[/tt] dit à ce thread de s'activer un peu, et le [tt]yield()[/tt] rend finalement la main au système.

En particulier, le page cache cherche d'abord à vider ses pages modifées et non réécrites sur disque avant de chercher à s'accaparer un peu plus de RAM (try_to_free_pages s'adresse aux autres processus qui utilisent de la mémoire)
...

Donc, le cache fonctionnerait en lecture mais aussi en écriture [:figti]
Une page modifiée pourrait être conservée "longtemps" dans ce cache sans être écrite :??:

edit : quoique, j'ai un doute. Ce bdflush, il écrit les pages modifiées du cache ? Ou les pages modifiées de la RAM (des autres process) ?

Message édité par mrbebert le 02-07-2003 à 20:04:18

glacote

mrBebert a écrit :

Oui, les pages sales (modifiées en écriture en RAM mais pas encore écrites sur le disque) ne sont pas écrites tout de suite. Si un autre processus essaie d'accéder à cette portion du fichier, il se voit remis la copie en mémoire, qui est toujours à jour. Au bout d'un certain temps, les pages sont écrites sur le disque (en groupant les écritures). C'est un paramère à règler, mais je ne l'ai pas retrouvé à l'époque où je l'avais chercher pour limiter les accès au disque de mon portable et permettre sa mise en veille.

bigsheet

Je vais bientot acheter un dd, c quoi la conclusion de toutes ces discussions, ca vaut le coup un 8mo sachant qu'il faut payer au moins 25 euros de plus, en gagne cb en sec ou msec de plus ?

mrbebert

Ce n'est pas un peu risqué de dire à l'application que l'enregistrement a été effectué alors que l'écriture sur le disque n'est pas faite ? S'il y a une coupure brutale ?

Ou alors, ca se joue sur un temps très court et l'OS fait en sorte d'écrire ces pages "rapidement" ? [:figti]

vingtcent

C'est c'laaaa ouiiii !

Bigsheet a écrit :

Je vais bientot acheter un dd, c quoi la conclusion de toutes ces discussions, ca vaut le coup un 8mo sachant qu'il faut payer au moins 25 euros de plus, en gagne cb en sec ou msec de plus ?

niveau perf je ne sais pas, mais juste les deux annnées de garantie supplémentaires vallent la dépense a mon sens.

Par contre la diff n'est pas de 25? mais bcp moins en fct de la boutique

Message édité par vingtcent le 02-07-2003 à 20:31:46

glacote

Bigsheet a écrit :

Je vais bientot acheter un dd, c quoi la conclusion de toutes ces discussions, ca vaut le coup un 8mo sachant qu'il faut payer au moins 25 euros de plus, en gagne cb en sec ou msec de plus ?

Ne te pose pas la question, ça vaut le coup rien qu'à cause de la garantie de 3 ans au lieu d'un ...

vingtcent

C'est c'laaaa ouiiii !

glacote a écrit :

ça vaut le coup rien qu'à cause de la garantie de 3 ans au lieu d'un ...

copaing

Publicité

Page : 1 2 3 4 5 6 7 8 9 10 11 12

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Hardware

Disque dur

Intérêt du cache 8Mo [Ca ne sert à rien (?), benchmark inside]

Sujets relatifs
[Question de nOOb inside] - Mettre à jour son BIOS	[Topic Unique] Monter un système Sata-Raid (Sil3112 Inside)
Une nouvelle config (cm, proc, ram). Que choisir?? (athlon inside)	[écran] à quoi sert le moiré?
Disque dur Maxtor Diamond 9+ (8Mo)	Utilitaire Maxtor qui ne détecte rien
Mémoire tampon disque dur... Utilitéde 8Mo en utilisation standard?	A koi sert un carte tuner tv exactement ?
les IFO sur le DVD ca sert a quoi ?	reconnaitre un 8Mo d'un 2Mo
Plus de sujets relatifs à : Intérêt du cache 8Mo [Ca ne sert à rien (?), benchmark inside]

Page générée en 0.073 secondes