Utvecklare från Cloudflare om att utföra arbete för att optimera prestandan för diskkryptering i Linux-kärnan. Som ett resultat var de förberedda för delsystem och Crypto API, som gjorde det möjligt att mer än fördubbla läs- och skrivgenomströmningen i det syntetiska testet, samt halvera latensen. När den testades på riktig hårdvara reducerades krypteringsoverheaden till nästan den nivå som observerades när man arbetade med en disk utan datakryptering.
Cloudflare använder dm-crypt för att kryptera data på lagringsenheter som används för att cachelagra innehåll på CDN. Dm-crypt fungerar på blockenhetsnivå och krypterar skriv-I/O-förfrågningar och dekrypterar läsbegäranden, och fungerar som ett lager mellan blockenheten och filsystemdrivrutinen.
För att utvärdera prestandan för dm-crypt med hjälp av paketet Vi mätte hastigheten för att arbeta med krypterade och okrypterade partitioner på en RAM-disk som finns i RAM för att eliminera fluktuationer i diskprestanda och fokusera på kodprestanda. För okrypterade partitioner förblev läs- och skrivprestanda på 1126 MB/s, men hastigheten minskade när kryptering aktiverades 7 i tiden och uppgick till 147 MB/s.
Till en början uppstod misstankar om användningen av ineffektiva algoritmer i kärnans kryptosystem. Men testerna använde den snabbaste algoritmen, aes-xts, med 256 krypteringsnycklar, vars prestanda när man kör "cryptsetup benchmark" är mer än dubbelt så hög som resultatet som erhålls när man testar en RAM-disk. Experiment med dm-crypt-flaggor för prestandajustering gav inga resultat: när flaggan "--perf-same_cpu_crypt" användes, minskade prestandan till och med till 136 MB/s, och när flaggan "--perf-submit_from_crypt_cpus" specificerades ökade den bara till 166 MB/s.
En djupare analys av driftlogiken visade att dm-crypt inte är så enkelt som det verkar - när en skrivbegäran kommer från FS-drivrutinen bearbetar dm-crypt den inte direkt, utan placerar den i "kcryptd"-kön, vilket analyseras inte omedelbart, men när det är lämpligt ögonblick. Från kön skickas begäran till Linux Crypto API för att utföra kryptering. Men eftersom Crypto API använder en asynkron exekveringsmodell utförs kryptering inte heller omedelbart, utan kringgår en annan kö. Efter att krypteringen är klar kan dm-crypt försöka sortera väntande skrivförfrågningar med hjälp av ett sökträd . I slutet hämtar en separat kärntråd igen, med en viss fördröjning, de ackumulerade I/O-förfrågningarna och skickar dem till blockenhetsstacken.
Vid läsning lägger dm-crypt först till en begäran till "kcryptd_io"-kön för att ta emot data från enheten. Efter en tid blir data tillgänglig och placeras i "kcryptd"-kön för dekryptering.
Kcryptd skickar en begäran till Linux Crypto API, som dekrypterar informationen asynkront. Förfrågningar går inte alltid igenom alla köer, men i värsta fall hamnar en skrivförfrågan i köer upp till 4 gånger, och en läsbegäran upp till 3 gånger. Varje träff i kön orsakar förseningar, vilket är huvudorsaken till den betydande minskningen av dm-crypt-prestanda.
Användningen av köer beror på behovet av att arbeta under förhållanden där avbrott uppstår. 2005, när dm-crypts nuvarande köbaserade operativa modell implementerades, var Crypto API ännu inte asynkront. Efter att Crypto API överfördes till en asynkron exekveringsmodell började i huvudsak dubbelt skydd användas. Köer infördes också för att spara konsumtion av kärnstacken, men efter ökningen 2014 förlorade dessa optimeringar sin relevans. En extra kö "kcryptd_io" introducerades för att övervinna flaskhalsen som resulterar i att man väntar på minnesallokering när ett stort antal förfrågningar kommer. Under 2015 infördes ytterligare en sorteringsfas, eftersom krypteringsförfrågningar på multiprocessorsystem kunde slutföras ur funktion (istället för sekventiell åtkomst till disken utfördes åtkomsten i slumpmässig ordning och CFQ-schemaläggaren fungerade inte effektivt). För närvarande, när du använder SSD-enheter, har sortering förlorat sin mening, och CFQ-schemaläggaren används inte längre i kärnan.
Med tanke på att moderna enheter har blivit snabbare och smartare, har resursdistributionssystemet i Linux-kärnan reviderats och vissa delsystem har designats om, säger Cloudflares ingenjörer dm-crypt har ett nytt driftläge som eliminerar användningen av onödiga köer och asynkrona samtal. Läget aktiveras av en separat flagga "force_inline" och för dm-crypt till formen av en enkel proxy som krypterar och dekrypterar inkommande förfrågningar. Interaktion med Crypto API har optimerats genom att uttryckligen välja krypteringsalgoritmer som fungerar i synkront läge och inte använder förfrågningsköer. Att arbeta synkront med Crypto API fanns en modul som låter dig använda FPU/AES-NI för acceleration och direkt vidarebefordrar krypterings- och dekrypteringsförfrågningar.
Som ett resultat, när man testade en RAM-disk, var det möjligt att mer än fördubbla prestandan för dm-crypt - prestanda ökade från 294 MB/s (2 x 147 MB/s) till 640 MB/s, vilket är mycket nära prestanda för ren kryptering (696 MB/s).
När man testade belastning på riktiga servrar visade den nya implementeringen prestanda mycket nära konfigurationen som kördes utan kryptering, och att aktivera kryptering på servrar med Cloudflare-cache hade ingen effekt på svarshastigheten. I framtiden planerar Cloudflare att överföra de förberedda patcharna till Linux-huvudkärnan, men innan dess kommer de att behöva omarbetas, eftersom de är optimerade för en specifik belastning och inte täcker alla applikationsområden, till exempel kryptering på låg -ström inbäddade enheter.
Källa: opennet.ru