Розробники з компанії 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