Распрацоўнікі з кампаніі Cloudflare аб правядзенні працы па аптымізацыі прадукцыйнасці дыскавага шыфравання ў ядры Linux. У выніку былі падрыхтаваны для падсістэмы і Crypto API, якія дазволілі ў сінтэтычным тэсце больш за ў два разу падняць прапускную здольнасці пры чытанні і запісы, а таксама ў два разу зменшыць затрымкі. Пры тэставанні на рэальным абсталяванні накладныя выдаткі ад шыфравання атрымалася зменшыць практычна да ўзроўня, назіранага пры працы з дыскам без ужывання шыфравання дадзеных.
Cloudflare выкарыстоўвае dm-crypt для шыфравання дадзеных на назапашвальніках, якія выкарыстоўваюцца для кэшавання кантэнту ў CDN-сеткі. Dm-crypt працуе на ўзроўні блокавай прылады і выконвае шыфраванне запытаў уводу/высновы на запіс і расшыфроўку запытаў на чытанне, выступаючы ў ролі праслойкі паміж блокавай прыладай і драйверам файлавай сістэмы.
Для адзнакі прадукцыйнасці dm-crypt пры дапамозе пакета было выраблена вымярэнне хуткасці працы з шыфраванымі і незашыфраванымі часткамі на RAM-дыску, размешчаным у АЗП для выключэння флуктуацый прадукцыйнасці дыскаў і факусаванні на прадукцыйнасць кода. Для незашыфраваных частак прадукцыйнасць чытання і запісы трымалася на ўзроўні 1126 MB/s, але пры ўключэнні шыфравання хуткасць знізілася у 7 раз і склала 147 MB/s.
Спачатку ўзнікла падазрэнне ў выкарыстанні неэфектыўных алгарытмаў у крыптасістэме ядра. Але ў тэстах выкарыстоўваўся найболей хуткі алгарытм aes-xts з 256 ключом шыфравання, прадукцыйнасць якога пры выкананні «cryptsetup benchmark» больш за ў два разу вышэй, чым атрыманы пры тэставанні RAM-дыска вынік. Эксперыменты са сцягамі dm-crypt для цюнінгу прадукцыйнасці не далі выніку: пры выкарыстанні сцяга "perf-same_cpu_crypt" прадукцыйнасць нават паменшылася да 136 MB/s, а пры ўказанні сцяга "perf-submit_from_crypt_cpus" узрасла толькі да 166.
Больш глыбокі разбор логікі працы паказаў, што dm-crypt не так просты як здаецца - пры паступленні ад драйвера ФС запыту на запіс, dm-crypt не апрацоўвае яго адразу, а змяшчае ў чаргу "kcryptd", якая разбіраецца не адразу, а пры наступе зручнага моманту. З чаргі запыт адпраўляецца ў Linux Crypto API для выканання шыфравання. Але бо Crypto API выкарыстае асінхронную мадэль выканання, шыфраванне таксама вырабляецца не адразу, а абыходзячы яшчэ адну чаргу. Пасля завяршэння шыфравання dm-crypt можа спрабаваць выканаць сартаванне якія чакаюць запытаў на запіс, выкарыстоўваючы дрэва пошуку . У канцы асобны струмень ядра ізноў з вызначанай затрымкай падхапляе назапашаныя запыты ўводу/высновы і адпраўляе іх у стэк блокавай прылады.
Пры чытанні спачатку dm-crypt дадае ў чаргу "kcryptd_io" запыт на атрыманне дадзеных з назапашвальніка. Праз нейкі час дадзеныя становяцца даступныя і змяшчаюцца ў чаргу "kcryptd" для расшыфроўкі.
Kcryptd адпраўляе запыт у Linux Crypto API, якія расшыфроўвае інфармацыю ў асінхронным рэжыме. Запыты не заўсёды праходзяць па ўсіх чэргах, але ў горшым сцэнары запыт на запіс асядае ў чэргах да 4 разоў, а запыт на чытанне да 3 разоў. Кожнае трапленне ў чаргу прыводзіць да ўзнікнення затрымак, якія і з'яўляюцца ключавым чыннікам значнага паніжэння прадукцыйнасці dm-crypt.
Ужыванне чэргаў абумоўлена неабходнасцю працы ва ўмовах узнікнення перапыненняў. У 2005 году, калі была рэалізаваная бягучая мадэль працы dm-crypt на аснове чэргаў, Crypto API яшчэ не быў асінхронным. Пасля перакладу Crypto API на асінхронную мадэль выканання стала прымяняцца па сутнасці падвойная абарона. Чэргі таксама ўводзіліся для эканоміі спажывання стэка ядра, але пасля яго павелічэння ў 2014 годзе гэтыя аптымізацыі страцілі актуальнасць. Дадатковая чарга «kcryptd_io» была ўведзена для пераадолення вузкага месца, якое прыводзіць да чакання вылучэння памяці пры паступленні вялікай колькасці запытаў. У 2015 годзе дадаткова была ўведзена фаза сартавання, бо запыты шыфравання на шматпрацэсарных сістэмах маглі завяршацца не выконваючы парадак адпраўкі (замест паслядоўнага доступу да дыска, ажыццяўляўся доступ у выпадковым парадку, а таксама не эфектыўна працаваў планавальнік CFQ). У наш час пры выкарыстанні SSD-назапашвальнікаў сартаванне страціла сэнс, а планавальнік CFQ ужо не выкарыстоўваецца ў ядры.
Улічваючы тое, што сучасныя назапашвальнікі сталі хутчэй і разумнейшыя, сістэма размеркавання рэсурсаў у ядры Linux была перагледжана а некаторыя падсістэмы перапрацаваны, інжынеры Cloudflare у dm-crypt новы рэжым працы, пазбаўлены ад выкарыстання лішніх чэргаў і асінхронных выклікаў. Рэжым уключаецца асобным сцягам «force_inline» і прыводзіць dm-crypt да формы простага проксі, які шыфруе і расшыфроўвае якія паступаюць запыты. Узаемадзеянне з Crypto API было аптымізавана відавочным выбарам алгарытмаў шыфравання, якія працуюць у сінхронным рэжыме і не выкарыстоўваюць чэргі запытаў. Для сінхроннай працы з Crypto API быў модуль, які дазваляе выкарыстоўваць FPU/AES-NI для паскарэння і напроста прабівае запыты шыфравання і расшыфроўкі.
У выніку атрымалася пры тэставанні RAM-дыска больш за ў два разу падняць прадукцыйнасць dm-crypt – прадукцыйнасць узрасла з 294 MB/s (2 x 147 MB/s) да 640 MB/s, што вельмі блізка да прадукцыйнасці голага шыфравання (696 MB /s).
Пры тэставанні нагрузкі на рэальных серверах новая рэалізацыя паказала прадукцыйнасць вельмі блізкую да канфігурацыі, якая працуе без шыфравання, а ўключэнне шыфравання на серверах з кэшам Cloudflare ніяк не паўплывала на хуткасць водгуку. У далейшым Cloudflare плануе перадаць падрыхтаваныя патчы ў склад асноўнага ядра Linux, але перад гэтым іх запатрабуецца перапрацаваць, бо яны аптымізаваныя для вызначанай нагрузкі і не ахапляюць усе вобласці ўжывання, напрыклад, шыфраванні на маламагутных убудаваных прыладах.
Крыніца: opennet.ru