Ouvrez Terminal, entrez :
sudo nvram boot-args="maxmem=8192"
et redémarrez. Cela limitera la RAM à 8 GiB. Maintenant, commencez à utiliser votre Mac avec la charge de travail habituelle.
Pour réactiver les 16 GiB-RAM complets, entrez simplement sudo nvram -d boot-args et redémarrez à nouveau.
Votre commande dd ne fonctionnera pas comme prévu, car le nombre de blocs écrits est de 0 (count=0) et la taille de bloc serait de 1 octet (bs=1). À ce que je sache, seul un "fichier" de la taille de 7 GiB est créé dans le catalogue du système de fichiers mais aucune donnée n'est réellement écrite dans le fichier lui-même. Si le count était de 1 (count=1), 1 octet de données aléatoires serait ajouté au fichier temp_7gb (seek=7g).
La destination (de=temp_7gb) est douteuse. Cela crée un fichier dans le répertoire de travail. Vous devez soit vous rendre dans un système de fichiers sur le disque RAM (par exemple, cd /Volumes/RAM-Disk/) d'abord pour créer le fichier là-bas, soit écrire directement sur le périphérique du disque RAM (of=/dev/devX).
dd est un outil qui mesure plutôt les entrées/sorties disque que la charge/vitesse du CPU ou l'utilisation de la mémoire.
Avec une combinaison astucieuse d'opérandes dd, vous pouvez encore l'utiliser pour simuler la charge CPU/l'utilisation de la mémoire.
if=/dev/urandom ou if=/dev/zero sont liés à la vitesse du CPUof=/dev/null le disque ne sera pas impliqué.bs=x détermine l'utilisation de la mémoire (x est presque proportionnel à l'utilisation de la mémoire)count=y vous donne du temps pour tester les choses
Exemples :
dd if=/dev/urandom of=/dev/null bs=1 count=1000
mesure principalement le surdébit des appels système (y compris toutes les atténuations Spectre / Meltdown que votre noyau utilise, ce qui rend les appels système plus lents qu'auparavant). Les nombres aléatoires cryptographiquement forts nécessitent également des calculs importants, mais 1 appel système par octet dominera cela. L'empreinte mémoire est faible (sur mon système environ 400 ko)
dd if=/dev/urandom of=/dev/null bs=1g count=10
mesure principalement la vitesse du CPU car il doit calculer beaucoup de données aléatoires. L'empreinte mémoire est élevée (sur mon système environ 1 Go). bs=1m serait à peu près la même chose mais utiliserait beaucoup moins de mémoire.
dd if=/dev/zero of=/dev/null bs=1g count=10
mesure principalement la bande passante mémoire (ici ~7 Go/s) pour le pilote /dev/zero du noyau réalisant un memset dans l'espace noyau dans le tampon de dd. L'empreinte mémoire ~= taille du tampon, qui est beaucoup plus grande que tout cache. (Certains systèmes avec des graphiques Iris Pro auront 128 MiB ou 256 MiB de eDRAM ; tester avec bs=128m vs bs=512m devrait montrer cette différence.)
Le pilote /dev/null du noyau jette probablement les données sans même les lire donc vous mesurez simplement la bande passante d'écriture mémoire, pas d'écriture + lecture alternée. (Et le surdébit des appels système devrait être négligeable avec seulement une lecture + écriture pour 1 Go stocké.)
dd if=/dev/zero of=/dev/null bs=32k count=100000
mesure principalement la bande passante d'écriture de la mémoire cache CPU (ici ~13 Go/s) et le surdébit des appels système. Le CPU n'a pas grand-chose à calculer (des zéros !) ; l'empreinte mémoire est faible (sur mon système environ 470 ko).
La taille de la cache L1d est de 32 ko. Vous penseriez que bs=24k serait plus rapide (parce qu'il s'adapte facilement à la cache L1d au lieu d'avoir plus d'évictions car le tampon de dd n'est pas la seule chose dans la L1d), mais le surdébit des appels système par ko copié pourrait le rendre pire.
La cache L2 fait 256 ko, la L3 est de 3 à 8 MiB. bs=224k devrait avoir une très bonne bande passante. Vous pouvez exécuter dd sur chaque cœur en parallèle et la bande passante augmentera car les caches L2 sont privées par cœur, contrairement aux L3 partagées et à la DRAM. (Sur les systèmes Xeon à plusieurs cœurs, il faut plusieurs cœurs pour saturer la bande passante de la DRAM disponible, mais sur un bureau/portable, un cœur peut s'en approcher assez près.)
