Výkon iSCSI přes ethernet, optimalizace

[frelichl]

Nemuzu rict, ze bych tomu zrovna rozumnel, ale vsechna mereni vykonu XORu (pro RAID) anebo rychlosti sifrovacich algoritmu (pro TrueCrypt etc.) mi pripadaji velmi malo vypovidajici. Zasadni rozdil je imho v tom, ze neni prakticky mozne pouzit DMA. V normalim modu mate nejaky blok pameti, ktery potrebujete dostat na disk, procesor zinicializuje prenos a zbytek se dodela sam, neni nutne protocit vsechna data pres procesor.

V momente, kdy nad temi daty potrebujete spocitat XOR nebo v horsim pripade je zasifrovat nutne musite vsechno pres procesor propasirovat a rozhodne to nemuze fungovat tak, ze CPU spocita XOR pro vsechna data najednou tou rychlosti, kterou si muzete zmerit, pak je hotovo a jede se jako normalne. IO operace jsou vyrazne pomalejsi, bude tam hodne, hodne context-switchu a ve vysledku bude procesor castecne zaneprazdneny danou IO operaci po celou jeji dobu. Vyvedte me nekdo prosim z omylu, ale presne takhle si ja vysvetluju, ze laptop se sifrovanym diskem je citelne pomalejsi nez ten s nesifrovanym diskem, at jsou testy vykonu ohromujici jak chteji.

Mluvim samozrejme softraidu a softsifrovani...

[Fox!MURDER]

...

takhle by to bylo, pokud by nad tim nikdo vubec nepremejslel a udelal to nejjednodussim zpusobem ...

jinak ale staci obetovat trochu pameti na buffery a neni problem ...

viz. zapis na

Cipher name:    aes
Cipher mode:    xts-essiv:sha256
Hash spec:      sha512

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00    0.00  475.00     0.00   211.21   910.64     0.26    0.55    0.00    0.55   0.47  22.50
dm-0              0.00     0.00    0.00  475.00     0.00   211.21   910.64     0.22    0.46    0.00    0.46   0.39  18.70
sdc               0.00     0.00    0.00  557.00     0.00   247.74   910.91     0.30    0.54    0.00    0.54   0.45  25.10
dm-0              0.00     0.00    0.00  557.00     0.00   247.74   910.91     0.26    0.46    0.00    0.46   0.39  21.60
sdc               0.00     0.00    0.00  495.00     0.00   220.21   911.11     0.28    0.56    0.00    0.56   0.47  23.30
dm-0              0.00     0.00    0.00  495.00     0.00   220.21   911.11     0.23    0.47    0.00    0.47   0.40  19.80

----total-cpu-usage---- ---system-- ---io/sdc-----io/dm-0-- --dsk/sdc-----dsk/dm-0-
usr sys idl wai hiq siq| int   csw | read  writ: read  writ| read  writ: read  writ
  0  83   0  15   0   3|4592  3045 |   0   507 :   0   507 |   0   225M:   0   225M
  0  96   0   2   0   2|4728  1249 |   0   619 :   0   620 |   0   275M:   0   275M
  0  78   0  21   0   1|5363   881 |   0   486 :   0   488 |   0   217M:   0   217M
  0  78   0  21   0   1|5379  1033 |   0   479 :   0   477 |   0   212M:   0   213M

context switchu tam moc neni a preruseni taky ne (vzhledem k tomu, ze 4000 je klidovej stav pri 4 CPU a HZ=1000 kernelu)
HW: 1x Xeon E5504, Areca 1680, 5x2TB WD2002FYPS RAID6, 6GB RAM

(samozrejme se jedna o velmi jednoduchej test-case - sekvencni zapis na fs)
(ty vypisy jsou chycene v rozdilnych casech - jsou spis informativni, nez aby mely velkou vypovidaci hodnotu)
(zkusim jeste najit nezatizenej sw raid5/6 ...)

A nemuzu ted narychlo najit benchmark kernelove implementace AES256-XTS, ale pro obrazek rychlost OpenSSL implementace AES-256-CBC pri vyuziti vsech 4 jader (kernel ma AES implementovany v assembleru a tim padem o neco rychlejsi).

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc     171594.18k   179896.87k   182058.07k   182586.71k   182591.49k

btw. marty - nahod komplet konfigurak ietd ...

[frelichl]

Fox: jasne, nerikam, ze je to udelane tak hloupe, ale princip je jasnej: vsechno musi projet pres registry procesoru, ze to jde udelat blokove je samozrejme podstatna optimalizace, ale jde to vzdycky delat po rozumnych blocich?

HollyG: nerikam, ze je to v prumernem pripade extra pomalejsi, ale jsou situace, kdy notebook se sifrovanym diskem bezpecne poznam. Ale taky samozrejme zalezi na konkretni implementaci, specialne ta, co mam na pracovnim notebooku mi pekne pije krev.

[Fox!MURDER]

Fox: jasne, nerikam, ze je to udelane tak hloupe, ale princip je jasnej: vsechno musi projet pres registry procesoru, ze to jde udelat blokove je samozrejme podstatna optimalizace, ale jde to vzdycky delat po rozumnych blocich?

HollyG: nerikam, ze je to v prumernem pripade extra pomalejsi, ale jsou situace, kdy notebook se sifrovanym diskem bezpecne poznam. Ale taky samozrejme zalezi na konkretni implementaci, specialne ta, co mam na pracovnim notebooku mi pekne pije krev.

ono ani tak neni problem v rozdeleni do bloku ... koneckoncu to v blocich musi byt vzdy.
problem je v tom, ze kdyz to nemas v blocich, musis precist co uz na disku je, zmenit to, co zmenit chces a zase to zapsat (a to plati jak pro raid - problem pri velkem stripe, tak pro sifrovani - tam bloky nastesti nejsou tak velke)
a nakonec, marty ma problem i se ctenim a to v raid5 skrz cpu projit nemusi ...

[HollyG]

Ja tedy notebook s sifrovanym diskem pouzivam a ze by byl nejak extra pomalejsi to mi neprijde