Reprise du message précédent :
sinon pour avoir un camparo 2mo/8mo pour le même drive:
 
le JB c'est le 8Mo, le BB le 2Mo.
 
http://www.storagereview.com/php/b [...] 9&devCnt=2

ce qui me surprend toujours dans ces tests c'est :
- on ne sait pas sur quoi celà a été testé (OS, patche, controleur IDE...) et celà peut avoir de l'influence...
De plus le comparatif ne garantie pas que celà a été testé sur des machines identiques...
- pourquoi le 8Mo est plus bruyant que le 2 Mo ?  

Pour que les choses soient tout-à-fait claires
(lu sur http://bulmalug.net/body.phtml?nIdNoticia=1154)
 
[citation]
All modern Unix systems allow file system data to be accessed using two mechanisms (Figure two).  
 
Memory mapping with mmap: The mmap() system call gives the application direct memory-mapped access to the kernel's page cache data. The purpose of mmap is to map a file data into a VMS address space, so data in the file can be treated as a standard in-memory array or structure. File data is read into the page cache lazily as processes attempt to access the mappings created with mmap() and generate page faults.  
Direct block I/O system call such as read and write: The read() system call reads data from block devices into the kernel cache (avoided for CD and DVD reading by means of O_DIRECT ioctl parameter), then it copies data from the kernel's cached copy onto the application address space. The write() system call copies data in the opposite direction, from the application address space into the kernel cache and eventually, in a near future, writing the data from the cache to disk. These interfaces are implemented using either the buffer cache or the page cache to store the data in the kernel.  
[/citation]
 
Donc il est possible de demander au système à accéder à la totalité d'un fichier directement depuis la RAM, à charge pour lui d'aller lire ce qu'il faut au fur-et-à mesure (d'ù les buffer et page caches).

Merci pour le lien.
1) seuls les tests applicatifs ont de l'importance, puisqu'il ne fait aucun doute qu'à bas niveau mieux valent 8Mo que 2Mo ! Il faut laisser à l'OS la possibilité de gérer son propre cache.
2) pour la partie "WinBench", OK, 8Mo > 2Mo
   pour la partie serveur, kif-kif.
 
J'en conclus (personnellement) que:
1) le cache 8Mo ne sert à rien.
2) peut-être que les disques équipés en usine de 8Mo sont ceux qui sont les meilleurs physiquement (moins de bad-blocks à réallouer, etc.), d'où des perfs intrinsèquement meilleures (??).

je ne vois pas en quoi les points soulevés confirme ce que tu indique   Pour moi, le test confirme bien que 8Mo peuvent apporter quelque chose par rapport à 2 Mo, mais celà est fonction de l'utilisation qui est faite des disques. Non ?

 
je suis tenté de dire : ... et alors ?

 
oui, sous windows aussi, et c'est comme ça qu'est implémenté le swap sous tous les OS en général (sous Windows les mémoires partagées sont aussi faites via le jeu d'API qui permet de mappper des fichiers).  
mais bon c'est un peu hors-sujet par rapport au cache HD. (c'est à un niveau supérieur dans l'OS).

Bah l'idée du mmap c'est juste que tu peux expréssement indiquer à l'OS que tu veux que tout ton fichier soit mis en RAM. S'il y a assez de place libre en RAM pour le page cache, et si (et là est toute la question/le coeur du topic) l'algo qui recharge le page cache est assez malin pour ne pas charger les pages une par une mais 1000 par 1000, alors pour accéder à ton fichier l'OS ne fait que des requêtes de 4Mo par 4Mo de secteurs consécutifs. Si on suppose en plus (je prétends que c'est le cas, mais à vérifier) que la numérotation des secteurs LBA reflète directement l'agencement physique (genre une fonction affine quoi; deux secteurs contigus ont des numéros LBA contigus), alors ça revient à dire que quand tu accèdes à un fichier avec mmap, en fait tu ne le lis que par salves de 4Mo de secteurs physiques contigus. Auquel cas, donc, le cache intégré ne sert à rien.
Il reste 3 questions (je crois):
1) on n'utilise pas toujours mmap; avec des read/write directs, on passe par le page-cache directement, ça empêche peut-être l'algo de fonctionner correctement. Je ne crois pas mais bon ...
2) l'algo en question est-il plus malin que celui implémenté sur le contrôleur intégré au disque (ça me semble évident mais bon ...) ?
3) est-ce vrai que les secteurs de numéro LBA n et n+1 sont forcément contigus sur le disque
(hors réallocation due aux bad blocks) ? Je ne vois pas l'intérêt de faire autrement, à part pour faire exprès d'induire les OS en erreur, mais bon ...

OK à en juger par le test Ziff Davis bureautique. J'étais plutôt parti sur un serveur de fichie au début du topic, ce qui me semble plus représentatif.
 
PS: encore une fois pour ma part je n'achète que des 8Mo (pour la garantie). La question est de savoir si ça apport quelque chose et si oui pourquoi. J'ai beaucoup de contre-arguments sur le fait que ça apporte quoi que ce soit. Pour le test Ziff Davis, j'en déduis que soit la gestion du cache par Win32 est pourrie (puisqu'un pauvre contrôleur intégré à un disque avec 8Mo de RAM toute pourrie fait mieux), soit que les disques qui sortent d'usine avec 8Mo sont par ailleurs plus fiables/performants. Je crois avoir lu sur le comparatif de HFR que les perfs. de bas niveau sont meilleures même par exemple en débit soutenu, là où le cache ne sert à rien (ou alors je n'ai décidément rien compris). cf les ATI avec 2 pipelines dont on peut certes réactiver les 2 autres, mais qui s'overclockent moins bien qu'une "vraie" 4 pipeline. Ou cf les Athlon XP à ponts reliés moins overclockables que les "vrais" Athlon MP. Mais là ce ne sont que suppositions non étayées de faits. Il faudrait voir aussi les taux de retour SAV.

 
je vois pas trop comment t'expliquer que tu es hors sujet en parlant de mmap et de manière générale les fichiers mappés en mémoire.
 
déjà quand tu fais un mmap, le fichier n'est pas explicitement mis en mémoire, c'est que dans l'espace du process, pour un fichier de 64 mo, et donc un mappage de 64 mo, quand tu ferais un accès dans la fenêtre de 64 mo, tu généreras une "page fault" qui fera que l'os chargera un bloc de donnée de la taille d'une page (4ko ou 4mo suivant PAE ou pas) et que tu pourras ainsi accéder.
 
avec un fichier mappée en mémoire, les données dont chargées "à la volée" ou fur et à mesure des accès mémoires.
 
donc si tu mappes un fichier de 128 mo, et que tu accèdes à 1 mo à la fin puis à 2 mo au début et ensuite 4 mo au centre, l'os chargera & cachera uniquement les 7 mo en ram (en faisant la séquence à la demande 1mo/fin, 2mo/debut, 4mo/centre).
 
De la même manière lors d'une allocation mémoire sous Windows ou Linux, si tu alloues un bloc de 1 Go de RAM avec un PC qui a 64 Mo, l'OS te retournera un pointeur valide, et au fur et à mesure que tu te baladeras dans la zone de 1 Go, des pages mémoires seront allouées dans la RAM physique quitte à balancer les pages mémoires les moins utilisées (du même process ou d'autres process) dans le Swap.
 
mmap ne consiste pas à charger en vrac un fichier de X Mo en mémoire, il consite à utiliser les routines de mappage mémoire de pages à la volée de l'OS (via le MMU) qui ont été initialement employées pour la gestion du SWAP, pour pouvoir se balader dans un fichier volumineux comme si il était entièrement chargé en mémoire de manière virtuelle.
 
Effectivement avec un fichier mappé en mémoire que ce soit sous Linux ou sous Windows, si ton process balayes l'espace mémoire représentant le fichier linéairement, le fichier sera lu séquentiellement (mais forcément sequentiellement d'un point de vue du dur si le fichier est fragmenté), mais si tu fais des accés aléatoires, les accès disques seront quasiment tout aussi aléatoires et suivront le séquencement des accès mémoires.
 
-quasiment- car effectivement entre les deux il peut y avoir une autre couche de cacheage de donnée et de système d'anticipation.
 
-----------
 
tout ça pour dire que mmap est à un niveau d'abstraction supérieur au cache HD, et c'est pas vraiement en réfléchissant à ce niveau que tu pourras mettre en évidence qu'un cache coté contrôlleur du disque dur est pas super utile.

OK merci pour ces précisions (mais je crois que j'avais à peu près compris). Mais je croyais (peut-être à tort) que le gestionnaire de cache, quand il y a une page fault, ne va pas juste charger la page manquante mais tout un paquet de pages à la fois (mon "1000 pages par 1000 pages" ). Si c'est le cas, c'est un peu comme si je n'en demandais qu'une mais que le cache intégré mettait les autres secteurs dans son cache; donc ça se substitue au cache. Si ça n'est pas le cas, OK, c'est complètement hors sujet.
Je voulais juste en citant mmap bien montrer qu'on passe par le page cache; quand on fait un read/write direct, on passe aussi par le buffer cache mais à cause des tampons internes dont je n'ai pas compris comment ils fonctionnaient.
cf

voilà, donc on en reviens au début:
 
l'os a un cache général, et ou l'on stoque les données déjà lues, et qui permet de stoquer des données que l'on lit par anticipation.
 
et on reviens à l'argument de base:
 
le firmware du disque dur connait mieux la conception du dur que l'os, donc son cache est complémentaire à celui de l'os.

OK si tu le dis. Mais je suis désolé dêtre boulet/d'insister, je ne comprends pas pourquoi.
Ce que le disque connaît = les secteurs physiques
Ce que l'OS connaît = les secteurs logiques (LBA) + la liste des secteurs dont on aura bientôt besoin (via la FAT/table des inoeuds).
Je prétends que le passage LBA <-> secteurs physiques est trivial, et en particulier que deux secteurs LBA n et n+1 sont contigus physiquement sur le disque. Si c'est faux, OK, fin du topic. Si c'est vrai, bah ...

si un firmware était aussi trivial, on aurait jamais vu le raptor beta avec des performances pourries, puis ensuite le raptor final en haut des podiums...

Désolé je ne savais pas. Mais je suppose que dans le firmware contient surtout les algos de correction d'erreur et le calibrage du DSP. Peut-être aussi la façon d'agencer les secteur logiques sur le disque, mais là je ne vois pas en quoi on peut "améliorer" quoi que ce soit:
qu'est-ce qui peut exister de mieux que l'agencement qui fait en sorte qu'une fois que tu as lu le secteur logique n, les têtes+le bras+le DSP sont prêts à lire le secteur n+1 ? Etre prêt à lire le secteur 37035 ? Pourquoi faire ? Peut-être que je rate quelque chose, mais je ne comprends toujours pas l'intérêt d'agencer les secteurs autrement (?).

je pense pas que ce soit une question d'agencement...
 
en fait le fait est là: même avec des centaines de mo de ram pour le cache os, on peut mesurer la différence entre un cache 8 mo et un 2 mo lors de tests pratiques.
 
par contre il serait interressant de trouver des benchmarks (bureautique pas serveur) sous linux pour savoir si le cache de windows est à prendre en défaut.
 

Euh ... pas sûr (cf bench en mode serveur, plus HD-intensif que bureautique). Mais bon, meêm si c'est vrai j'aimerais vraiment comprendre pourquoi. Est-ce parce que le disque est en faif physiquement plus rapide ? Est-ce parce que le cache disque des OS est complètement neuneu, vu qu'il n'arrive pas à faire avec 300Mo de RAM à 4Go/s ce qu'un pauvre contrôleur fait avec 6Mo de RAM toute lente ? Est-ce parce que la conversion LBA <-> secteurs physiques n'est pas du tout triviale ? Est-ce parce qu'en fait quand il lit des données il pourrait les lire plus vite (mais ne le fait pas pour une raison inconnue), et se contente de remplir son cache avec ? J'ai vraiment des doutes, mais je ne veux pas non plus nier la réalité ...

et bin justement le passage LBA <-> secteurs physiques est loin d'être trivial puisque seul le disque sait où sont situé tes secteurs réels (cf remappage des secteurs lors de secteurs défectueux, fait au niveau du disque). Et non les secteurs ne sont pas obligatoirement contigues sur le disque. Pour des raisons d'efficacité le disque peut très bien entrelacer les données si celà l'arrange... enfin bref je pense que tu saisie le principe. Et comme dit BJone, les firmwares disques sont loin d'être triviaux. De plus tu pars d'un principe faux à mon sens, ou à vérifier : les développeurs d'OS savent mieux programmer les algo de cache que les développeurs de firmware... et là je ne te suit pas vraiment. Mais j'ai l'impression que l'on tourne en rond : pour moi il y a complémentarité. après il faut voir si le point critique de la taille du cache est de 8Mo, 4 Mo, 2 Mo, 64 Mo... et si le gain de perf vaut le delta de prix. voilà.

Merci pour ta réponse. OK pour la réallocation des secteurs défectueux, mais c'est marginal. Pour les autres secteurs, je persiste: le secteur LBA n+1 est placé là où les têtes+bras sont prêtes à lire une fois qu'elles ont lues le secteur n et qu'il a été traité par le DSP, précisément pour que si on demande le secteur n+1 après le secteur n il n'y ait aucune latence. Je me trompe peut-être, mais ça me paraît être la meilleure chose à faire quand on conçoit un disque dur, non ?
Quant au cache lui-même, même si les développeurs de firmware sont très malins, le hardware dont ils disposent est calamiteux par rapport à celui dont dispose l'OS. Aucun moyen d'avoir un algo sophistiqué; + l'OS, lui a la vraie liste des secteurs à lire vu qu'il a la FAT/table des inoeuds, ce que n'a pas le contrôleur (fragmentation). C'est pour ça que ça m'étonne. Sur un 386 SX-16MHz avec FP-RAM à 33MHz, j'étais d'accord pour acheter un disque avec 1Mo plutot que 512ko. Mais sur un Athlon 1.5GHz + DDR 4Go/s ...
Bref ça n'est sûrement pas un mal de mettre 8Mo, c'est comme de mettre 4Go de RAM. Mais si c'est pour aller sur le net, 4Go ne servent à rien. Moi il me paraissait logique que les 8Mo de cache intégré ne servent à rien. Si c'est faux, je voudrais bien finir par comprendre pourquoi. Désolé pour ceux à qui je casse les pieds à force d'insister ...

là je laisse tomber. Je ne vois pas en quoi la taille du cache te rend moins astucieux ni moins efficace. On sait pertinament que c'est dans l'exiguité que les developeurs ont été les meilleurs (cf les OS eux mêmes, maintenant faire printf "hello world" te prend 5 Mo de RAM). Tu persiste à ne pas prendre en compte les arguments comme quoi l'OS n'a pas toutes les informations pour optimiser à bas niveau les accès disques... tu persiste à dire que les secteurs sont contigues alors que rien, mais alors rien ne le prouve (la réallocation n'a rien de marginale - cf les tables de secteurs défectueux détectés dès l'usine - et elle prouve que le disque n'a aucune obligation de rendre tes secteurs contigües)... Tu persiste sur un postulat de base que tu considére comme bon : les algo des OS sont meilleurs. Tu persiste à dire que l'OS peut aussi précharger des secteurs plus vite que le disque (alors que c'est tout de même le disque qui aura le dernier mot, désactive le préfetch et le cache sur un disque SCSI et tu verras si le cache ne sert à rien, j'ai passé des années à optimiser les paramètres de mes disques SCSI). Donc je ne vois pas comment continuer la discussion. honnêtement le débat tourne en rond...

> là je laisse tomber.
Désolé
> Je ne vois pas en quoi la taille du cache te rend moins astucieux ni moins efficace.
Bah pourquoi 1Mo de cache sur les processeurs améliore-t-il les perfs de 10% par rapport à 512ko ? Tu n'es pas moins astucieux mais tu as beaucoup plus de chances de faire un cache hit, et en plus l'accès est infiniment plus rapide.
 
> On sait pertinament que c'est dans l'exiguité que les developeurs ont été les meilleurs (cf les OS eux mêmes, maintenant faire printf "hello world" te prend 5 Mo de RAM).
Bof. Je pense que ceux qui ont écrit la couche disk-I/O de Win32 ou de Linux y ont passé du temps. J'ai codé 100,000 lignes dans ma vie en ASM sur HP48, c'est marrant, mais il n'empêche que mon algo de cryptage avait beau être hyper-tight ça allait 10 fois moins vite que le même en Turbo-Pascal sur 386-SX 33MHz.
 
> Tu persiste à ne pas prendre en compte les arguments comme quoi l'OS n'a pas toutes les informations pour optimiser à bas niveau les accès disques...
Désolé de te saoûler. Mais oui, je persiste à ne pas comprendre, cf ci-dessous
> tu persiste à dire que les secteurs sont contigues alors que rien, mais alors rien ne le prouve (la réallocation n'a rien de marginale - cf les tables de secteurs défectueux détectés dès l'usine - et elle prouve que le disque n'a aucune obligation de rendre tes secteurs contigües)...
OK je n'ai rien prouvé. Pas trouvé sur le web non plus, même sur storage-review.com
Mais voilà: l'agencement qui fait que quand tu as fini de lire le secteur n tu es prêt à lire le secteur n+1 (ce qui ne veut pas dire que les secteurs sont contigus physiquement, vu que le temps que le DSP traite le signal le disque a tourné; + le problème des différents plateaux), je ne vois pas ce que l'on pourrais faire de mieux. Mais peut-être que je loupe quelque chose ...
Je dis ça sans ironie, si tu as un argument/une idée, je suis preneur, c'est effectivement le coeur.
 
> Tu persiste sur un postulat de base que tu considére comme bon : les algo des OS sont meilleurs.
Non, mais ils peuvent faire au moins aussi bien (au niveau de l'algo): il suffit d'implémenter dans le page-cache/buffer-cache reload celui du cache intégré, s'il est meilleur. Vu que le hardware est infiniment plus rapide, tu ne peux pas être plus lent (ou bien ??).
 
> Tu persiste à dire que l'OS peut aussi précharger des secteurs plus vite que le disque (alors que c'est tout de même le disque qui aura le dernier mot, désactive le préfetch et le cache sur un disque SCSI et tu verras si le cache ne sert à rien
Pas compris. Mon seul argument depuis le début c'est: l'OS se débrouille, grâce à ses propres tampons, pour ne faire des accès au disque que par gros paquets pas trop fréquents de données contigues. Je prétends que dans ce cas plus que 512ko de cache ne servent à rien.
 
> , j'ai passé des années à optimiser les paramètres de mes disques SCSI).
Je te remercie de ton expérience. Ce n'est pas l'avis des auteurs de l'article cité au début.
Par ailleurs j'ai moi-même fait 3 mois de stages sur l'optimisation de serveurs de flux vidéo, pour lesquels je m'étais déjà dit que plus de 512ko de cache ne servaient à rien (seul le débit compte vraiment, c'est un cas un peu limite).
 
> Donc je ne vois pas comment continuer la discussion. honnêtement le débat tourne en rond...
Désolé pour ça, merci de tes contributions en tout cas. Peut-être que quelqu'un qui en a la patience parviendra à m'expliquer ...

justement un flux vidéo est un flux continu.... (donc effectivement je suis assez d'accord que le taille du cache HD, passé une certaine taille ne sert plus à rien)
 
autre cas défavorable au cache HD: le firmware doit balayer une structure pour obtenir un cache hit, et donc plus le cache est grand, plus il y a d'entrées de cache, est donc plus la recherche sera longue.
 
contrairement à un CPU, où les lignes caches sont balayées par comparaison multiple, il y a presque autant d'unité de comparaison que de lignes de cache, le firmware d'un HD ne peut que balayer les entrées par boucle logicielle, donc un plus gros cache augmente le nombre de hit rate, mais augmente le temps logiciel coté firmware (après fo voir si c'est significatif).
 
donc il est vrai, qu'il est difficile de trouver la raison technique à pourquoi "plus de cache => plus de perf en utilisation desktop", mais les benchs sont là: il y a un gain (variable suivant les cas)
 
il est plus facile je pense d'optimiser l'écriture, le firmware tasse tout dans le cache, et réorganise tout comme ça lui plait pour avoir le meilleur rendement mécanique, la lecture doit être plus subtile car c'est plus coté algo d'anticipation qu'il faudrait regarder.
 
comme en utilisation pratique tu as des lectures/écritures entrelacées, avoir de plus de ram permet au firmware de conserver plus de données cachées (déjà lues ou cachées par un algo d'anticipation), et même temps pendant que ces données cachées sont conservées pouvoir tamponner des écritures.
 
on peut imaginer plein de situations: l'os demande une lecture de faible taille, dans la foulée le firmware continue de précharger des données (soit linéairement soit suivant un motif subtile), mais pendant ce temps de prefetch l'os envoie un block à écrire, vu que le firmware a le cache, il tamponne le block à écrire et laisse le prefetch de lecture se terminer.
 

je n'ai pas eu le temps detout lire mais j'apporte mon grain de sel (j'espere ke personne n'a deja dit ce ke je vais dire; sinon grand pardon)
 
le 8Mo pourrait etre plus utile dans le cas ou il y a plusieurs disques sur la meme nappe?  
 
vous en pensez quoi ?

c'est un argument qui a été soulevé en effet : l'occupation du bus permet au disque d'anticiper d'autres traitements...

J'ai po tout lu, mais je me pose une chtite question.
 
Le cache des DD est vu comme de la ram, ou comme un espace d'adressage?

il n'est pas vu pas l'OS. Il est géré uniquement par le disque.

Vi je sais ca.
 
Je me demandais juste si le cache DD stockait des données ou seulement des adresses (comme une pile mémoire)...

 
ok encore desole
mais je pense aussi ke les 8Mo servent au niveau securite non??
ca a deja ete souleve aussi??
 
mille fois pardon

Merci de ces précisions ...

+1
Cela dit, n'est-ce pas complètement marginal, vu la vitesse de la RAM et du CPU ?
 
 

Bah l'article en début de topic et le bench page 9 me laissent penser que pour un serveur le cache ne sert à rien, non ? C'est pourtant là qu'on pouvait s'attendre à ce qu'il soit le plus utile ... Pour les résultats en desktop, je ne comprends pas, mais pourtant j'essaie, visiblement j'ai un peu du mal ...
 

D'accord pour différencier lecture/écriture. L'optimisation de l'ordre des écritures, peut-être que le driver I/O De l'OS ne le fait pas, mais alors il est vraiment débile, ça n'est pas très compliqué (?): algo = 1) classer les écritures par ordre croissant de premier secteur 2) partir du dernier secteur où on avait écrit (et où se trouve à peu près la tête en ce moment) 3) faire les écritures
Non ?
 

Ceci est vrai aussi bien pour le cache intégré que pour le cache de l'OS. Je suis bien d'accord.
Mais justement, c'est le gros intérêt d'utiliser la RAM, c'est d'avoir un cache beaucoup plus gros (en plus d'être infiniment plus rapide).
 

Il se passe exactement la même chose au niveau du cache de l'OS:
1) j'ouvre un fichier en lecture/écriture.  
2) je lis un (petit) morceau; l'OS en profite pour charger un gros morceau dans son cache
(le contrôleur du disque aussi, mais il n'a que 8Mo de cache très lent à sa disposition)
3) je modifie un morceau un peu plus loin: si on admet qu'il se trouverait dans le cache du disque, alors il se trouvera aussi dans le cache de l'OS, vu que l'OS a 300Mo là où le disque n'en a que 8Mo. Donc la modification s'effectue directement en RAM dans le page-cache (si mmap) ou le buffer-cache (si fichier ouvert directement avec fopen).
4) Un peu plus tard (4 secondes), le démon de synchronisation du noyau kflushd va écrire toutes les pages sales du cache de l'OS, donc donner l'ordre au disque d'écrire effectivement mes modifications
A ce niveau, si le disque dur veut les garder en cache, c'est sa vie, il est libre, mais ça ne sert à rien. L'OS ne va certainement pas lui redemander ces données-là avant longtemps vu qu'il les a lui-même en cache.
 
Bref pour résumer: tout ce qui se passe au niveau du contrôleur (sous le south-bridge) pourrait aussi bien se passer au niveau du CPU/RAM (au-dessus du north-bridge), quitte à réimplémenter l'algo. Ce qui suppose, effectivement, que l'OS ait à travers les secteurs LBA la même connaissance que le disque qui lui connaît en plus les secteur physiques. Si cette supposition est fausse, fin du topic (pour moi en tout cas, ça me suffira). Si c'est vrai, bah ...

Je ne penses pas personnellement (pas testé, because RAID IDE => un seul disque par contrôleur !).
Avoir plusieurs disques, ça veut juste dire qu'il y aura contention sur la nappe. Plus de cache intégré au disque ne change rien au volume de données qui transitent sur la nappe, juste qu'il y a moins de déplacement des têtes.
Au contraire, le cache de l'OS évite d'avoir à accéder aux disques, donc limite la contention.
EDIT: vu l'argument de Janus_75. Effectivement pendant qu'il y a contention, le disque peut bosser ...

Pendant que j'y pense, l'intéret du cache risque pas d'être dépendant de l'OS qui tourne?
=> voir le fameux defrag cher aux divers windows et inutile sous nux...

Le développeur est peut-être même meilleur, mais le hardware dont il dispose est tout pourri. Comment peut-il faire aussi bien ? C'est le sens de mon exemple ci-dessous.
 

OK.
 

OK j'aurais dû préciser: la HP48 c'est un processeur Saturn 4 bits à 4MHz. L'idée était: même avec beaucoup d'efforts, impossible de lutter avec un langage tout pourri (le Turbo pascal passe par une machine virtuelle interprêtée) mais qui tourne sur un hardware bien meilleur. L'idée ici c'est de comparer la puce intégrée au disque avec ses 8Mo de RAM et son bus ATA 133Mo/s avec un Athlon 1.5Gz/DDR-SDRAM 4Go/s ...
 
 

Je disais ça au sens: donc c'est forcément comme ça que les secteurs sont agencés dans tous les disques durs. Je prétends juste que quelque soit le disque dur, une fois le cache désactivé, la façon la plus efficace de lire des données est de lire des secteurs LBA consécutifs. Ne fût-ce que parce que c'est comme ça que marche le DMA, qui ne sait rien faire d'autre à ma connaissance.
Or, si c'est vrai, je ne vois pas ce que connaître l'agencement physique apporte de plus. Contentons-nous de ne jamais faire que des grosses requêtes dont les secteurs LBA sont consécutifs, et nous aurons par design les meilleures performances possibles, cache ou pas.
Peut-être que ça n'est pas vrai, et j'aimerais vraiment avoir une réponse à cette question.
 
 

OK. L'exemple, c'était pour un cas extrême. Si l'OS se débrouille pour ne faire que des grosses requêtes de 4Mo de secteurs consécutifs, je pense que tout le monde est d'accord que le cache ne sert à rien.
 

OK. Mais pourquoi le cache du disque n'aurait-il pas le même problème ? Je ne dis pas que l'algo de l'OS est meilleur que celui du disque, je dis qu'il est possible d'avoir un algo au moins aussi bon, et que par ailleurs vu qu'on a un énorme CPU et beaucoup de RAM très rapide ce sera forcément mieux. Evidemment si les conditions font que le cache, quel qu'il soit, est inutile, nous sommes d'accord que le cache de l'OS ne sert à rien !
 
Merci de ta patience ...

le problème c'est qu'on manque de docs sur les contraintes et les subtilités au niveau HD

ce soirje lis ce topic, j'ai l'impression ke je vais apprendre beaucoup de chose! merci encore

Si tu permets que j'entraîne encore un peu ta patience ...
1)

la puce est peut-être spécialisée, mais quand même, elle tourne nécessairement à moins de 33MHz (Athlon 1.5GHz), idem pour la RAM. De toute façon l'algo de gestion du cache (qui choisit quoi mettre/retirer) est certainement très simple, du genre: lire 4 secteurs de plus à chaque lecture; pour faire de la place, effacer du cache les secteurs utilisés le moins récemment.
Quel que soit l'algo que tu emploies, je ne vois pas comment une puce même super maligne à<= 100MHz pourra battre mon Athlon à 1.5GHz sur le même algo codé en C ... OK du temps des 386, mais là
Exemple: combien ça coûte de faire émuler du SCSI sur de l'IDE par l'OS au lieu d'avoir un contrôleur SCSI ? Moins de 5% pendant une gravure sur mon Duron 900MHz. Alors que là il s'agit de traiter des gros volumes de données, ce qui est infiniment plus coûteux que n'importe quel algo qui décide juste de quelles données garder/jeter.
Non ?
 
2)  

Bof bof, il s'agit de décider quelles données charger/vider, pas de les traiter. Ca coûte combien ? 1000 cycles ? 10.000 cycles ? A 1.5 GHz ?
 
3)  

Coinché ! Un transfert DMA, c'est juste de dire au disque d'envoyer ses données directement à la RAM sans passer par le CPU. Rien à voir avec le fait que ces données, il les ait en cache ou non.
C'est juste l'occasion de souligner qu'implémenter l'algo au niveau OS, ça veut dire implémenter le choix des données à charger/vider, pas le traitement lui-même qui se fait en DMA ...
 
4)  

C'est bien le problème crucial à mon avis. C'est en théorie possible, mais je ne vois pas pourquoi le moindre fabricant de disques durs mettrait en oeuvre une autre organisation des secteurs physiques que celle qui fait que quand j'ai fini le traitement de la lecture du secteur LBA n, tout est prêt (têtes/DSP) pour traiter le secteur LBA n+1, pas le secteur LBA 30127.
 
 
5)  

J'ai peut-être tort, mais j'en doute fortement (il faut lui laisser 512ko quand même, pas 0ko, car il faut stocker au moins quelques blocs à cause de la syncrhonisation sur la nappe, mais je ne suis pas expert). Puisque je ne vais jamais lui demander deux fois la même chose, quand est-ce qu'il va pouvoir me donner des secteurs déjà en cache ? En tout cas quand j'avais manipé sur mes serveurs multimedia, virer le cache des contrôleurs ne changeait rien (il restait quand même le cache intégré aux disques, mais il était < 2Mo, c'étaient des Cheetah de 9 Go). C'est un cas extrême je suis d'accord, mais c'est pour justifier le principe.
 
6)  

Pas d'accord du tout, là. Le cache de l'OS peut très bien faire tout ça + gérer un cache bas niveau aussi intelligent que le disque (à supposer, donc, que le problème des secteurs LBA/physiques n'en soit pas un). Gardons toutes ces jolies sémaphores/multi-tâches. A chaque fois que l'on rencontre un appel à une fonction du genre "really_do_read_from_disk", remplaçons-là par une fonction qui gère son propre cache en RAM avec le même algorithme que le contrôleur du disque. On a juste déplacé le traitement de l'algo du contrôleur vers le CPU, au plus bas niveau possible de l'OS. Et on y a gagné un Ahtlon 1.5GHz et de la RAM à 4Go/s ...
 
7)  

Je te propose un entraînement intensif ...

pour l'émulation SCSI, je pense que glacote parle de la couche ASPI ou il y a un wrapper (basique) SCSI=>IDE.
 
c'est vrai que l'IDE a pas mal rattrappé le SCSI en rendement, mais c'est pas tellement dû à une émulation software, c'est essentiellement dû à la montée en bande passante, et au fait que maintenant TOUS les périphériques IDE sont DMA/UDMA (DMA étant le principe de transfert, UDMA étant une norme de transfert sur le bus IDE ne fonctionnant qu'en DMA).
 
pour l'aspect performances ASIC/CPU générique je suis entièrement d'accord avec janus_75, un bon exemple sont les cartes 3D qui à 300mhz explosent en performances un P4 à 4Ghz (j'aimerai bien voir ce qu'un P4 4Ghz peut développer en fillrate avec des triangles multitexturés avec filtrage trilinéaire & anisotropique le tout en virgule flottante).
 
ceci dit l'asic des HD est là pour l'aspect numérique/logique (gestion du cache et des transferts en fonction de la norme IDE) et l'aspect analogique (asservissement des têtes, traitement du signal). on peut donc pas remplaçer l'ASIC ou les ASICs d'un PCB de disque dur par un cpu purement générique (ou pourrait séparer le numérique et l'analogique, mais le rapport perf/prix serait pourri).

Merci encore pour ces réponses ...
1) Sources: pilote "ide-scsi" du noyau Linux, sorte de wrapper qui implémente les commandes SCSI et les traduits en IDE. Sous Linux tous les graveurs de CD sont en fait gérés comme des graveurs SCSI, quitte à émuler (ce n'est plus vrai avec la dernière version de cdrecord).
 
2) Pas compris le coup du "DMA implique que ça passe par le cache".
   Je suis bien d'accord qu'il faut un petit tampon de quelques secteurs (512ko) pour le transfert, mais ça n'a rien à voir avec le fait que les données demandées se trouvent ou non dans le cache. Si tu demandes des nouvelles données, les têtes vont les chercher, les posent dans le cache d'où elles sont ensuites émises sur la nappe => south bridge => north-bridge => RAM. Mais pour faire ça avoir plus que 512ko ne sert à rien, c'est juste un tampon de synchronisation/temporisation, non ?
 
3) Sur l'agencement secteurs physiques/LBA (visiblement j'aurais dû faire un topic à part), je ne suis définitivement pas d'accord (désolé). Soif n°LBA = f(n°physique). Même si f est hyper-compliquée, voire impossible à calculer pour le CPU (qui ne connait pas le délai calibrage thermique, la durée de traitement du DSP, les micro-variations de vitesse de rotation, etc.), ça ne change rien. Je prétends encore et toujours qu'après avoir lu le secteur LBA n, de numéro physique f-1(n), les têtes de lecteur sont juste au-dessus de f-1(n+1), qui peut se trouver très loin de f-1(n) si tu veux, peu importe. Mon argument "qui tue" pour ça c'est que quand tu fais un accès DMA, tu ne demandes que des secteurs consécutifs. Donc pour avoir le meilleur débit possible et éviter les latences indésirables, le disque dur a intérêt à faire en sorte que quand il vient de finir de lire le secteur n il soit pile poil prêt à lire le secteur n+1.
La conséquence c'est que l'agencement physique n'a aucune importance: même le contrôleur intégré, quand il vient de lire/d'écrire le secteur f-1(n), le mieux qu'il puisse faire n'est pas de lire/d'écrire un secteur à côté, puisque les têtes/bras ne sont pas prêts pour ça, le mieux qu'il puisse faire c'est de lire/d'écrire le secteur f-1(n+1), par définition.
 
4) "Le cache ne joue réellement que sur les petits transferts".
Tout-à-fait d'accord. Ce que je ne comprends pas, c'est pourquoi l'OS ferait tout un tas de petits transferts alors qu'il peut ne faire que quelques gros transferts. Il peut le faire au moins aussi bien que le fait le cache intégré au disque, c'est mon argument de base.
Soit tes accès sont par nature désordonnés/petits/fragmentés et même le cache intégré au disque ne parvient à rien. Soit tes accès sont désordonnés mais localisés à quelques Mo particuliers, et alors là le cache intégré de 8Mo est utile. Mais dans ce cas, l'OS peut tout aussi bien regrouper lui-même les lectures-écritures.
Je ne dis pas que l'OS pourrait supprimer tous les petits accès. Je dis que chaque fois que le contrôleur intégré peut le faire, l'OS pourrait le faire aussi bien.
 
5) Pas compris pourquoi on ne peut pas implémenter l'algo du contrôleur intégré au niveau de l'OS. Merci de cocher ce qui te paraît faux:
J'ai toutes les informations nécessaires (liste des secteurs LBA à lire), même plus (FAT/table des inoeuds, problème de la fragmentation). (?)
J'ai beaucoup plus de RAM, plus rapide. (?)
J'ai au moins autant de puissance de calcul disponible. (?)
 
6) Pas d'accord sur la puissance de calcul, please ! Une carte 3D, elle traite un volume énorme de données = opérations simples sur un gros volume. Le langage de programmation des  shaders n'est même pas Turing (pas de boucle while, nombre maximal d'instructions borné) !
Là ce qu'on cherche à faire, c'est décider avec une heuristique compliquée quelles plages de données on va précharger/vider de la RAM. Rien à voir avec les traiter/modifier/etc. Je suis bien d'accord qu'une puce spécialisée peut largement écraser un CPU, mais sur un algo qui traite peu de données et fait un raisonnement compliqué, j'en doute très fortement. Je renouvelle ma question: combien de cycles faut-il à un x86 pour choisir dans une liste de 1000 addresses de plages de données pour en choisir une et la virer/la recharger en RAM ? Un algo du genre Least-Recently-Used, c'est en 0(1) (virer la première plage, qui est la plus ancienne), et une insertion triée dans une liste chaînée c'est au pire du pire du 0(n). Donc ça coûte quoi, 10,000 cycles ? Soit 7 micro-secondes ? Et le contrôleur intégré à < 100MHz arriverait à faire la même chose en 700 cycles (avec 1000 plages ??) ? Halte au sketch !
Le contoleur intégré, il est surtout optimisé pour traiter les données, et là OK, il faut ça beaucoup plus efficacement que le CPU (il suffit de désactiver le DMA pour le voir).
 
Merci à ceux qui auront l'abnégation louable d'essayer encore de me tirer de ce faux pas ...

Au fait concernant mmap:
http://www.gnu.org/software/libc/NEWS
"Read-only stdio streams now use mmap to speed up operation by eliminating copying and buffer underflows"