[Black (Wooden Law)]

Originariamente inviato da sbaffo

@ liupen
mi sono perso ma mi fido.

Sì, devo ammettere anche anch'io ho dovuto rileggerlo qualche volta il commento essendo abbastanza complesso e articolato.

Originariamente inviato da @Liupen

Perchè? La lettura dei riferimenti di mappatura da RAM o da DRAM hanno una latenza trascurabile in entrambe i casi.

Se ho capito bene qui stai dicendo che c'è poca differenza tra leggere i dati di mappatura sulla RAM del sistema e la DRAM, giusto?

Originariamente inviato da @Liupen

2) Quantità maggiore di memoria su RAM di sistema opzionata da HMB rende l'ssd "più veloce"?

La risposta a questa domanda è più articolata, perchè l'ssd legge/scrive e si comporta in maniera diversa se i dati cercati o scritti sono piccoli (casuali) o grandi (sequenziali) e se il carico di lavoro è alto (QD alta) o basso (QD bassa).

Iniziando proprio dal mio errore: HMB è una memoria su cui giace una parte di mappatura (+ algoritmi di gestione).
In particolare la parte di mappatura che "recentemente" per il controller dell'ssd, è stata modificata.
Qundo si citano "metadati" si intendono esclusivamente gli algoritmi e nessun blocco, pezzo o frammento di file utente.

Riprendendo il punto 2), non devo confondere, come ho fatto, la L2P (mappatura o porzione di essa) con il caching dei dati o "metadati" come si vede citato e ho scritto io stesso.


Questo vuol dire che mi sono risposto alla mia domanda: perchè se ho 64 MB di HMB invece di 32 MB l'ssd non legge più velocemente o in generale non ho vantaggi prestazionali?

Il fatto che ci sia più memoria HMB disponibile:

in lettura - per il motivo detto sopra - non cambia le performanze. Non c'è una cache di dati da leggere di dimensione maggiore infatti; in realtà sono indirizzi... più indirizzi in memoria.
A questo proposito entra in gioco un ulteriore elemento, a discapito della velocità; la richiesta di lettura viaggia attraverso più livelli (controller dell'SSD → sistema operativo dell'host → RAM host) e poi il dato deve essere inviato indietro al controller per l'elaborazione. Una diminuzione di latenza perchè la mappatura è su RAM (quando c'è) VS aumento latenza per "round trip".

in scrittura si hanno le variazioni più interessanti per l'HMB.
Sempre ricordando bene che la memoria HMB su RAM contiene "solo" (tra virgolette) degli indici di mappatura, le istruzioni di livellamento contingenti o di garbage pre-scrittura (e nessun bit utente), emerge un principio: più il buffer di memoria HMB è grande, più indirizzi ci stanno, più la scrittura random ad alta frequenza (maggiori QD) o i dati sequenziali scritti sono veloci.
Gli indirizzi LBA infatti vengono scritti su RAM (più veloce) e più c'è buffer, più lo fanno a lungo. In particolare le scritture randomiche che sono accompagnati da parecchio overhead (che sono dati pure quelli e che ovviamente hanno i loro indirizzi di mappatura).

Qui molto semplicemente ho capito che non ha senso avere più spazio HMB se alla fine i dati da leggere sono sempre quelli e non aumentano, mentre ha più senso avere più spazio HMB per le scritture visto che si possono così scrivere più dati e quindi aumentare le performance, giusto?