Коли компанія Meta почала шукати кращий планувальник процесора для Linux для свого масштабного серверного парку, вона почала не з дата-центру. Початковою точкою став портативний ігровий ПК. У недавній технічній доповіді на конференції Linux Plumbers’ Conference в Токіо інженери Meta детально розповіли, як вони впроваджують SCX-LAVD, низьколатентний планувальник Linux, спочатку розроблений компанією Valve для Steam Deck, у промислових серверних середовищах, де працюють системи обміну повідомленнями, кешувальні сервіси та інші критичні компоненти інфраструктури. Неочікуваний висновок полягає в тому, що планувальник, створений для забезпечення плавної роботи ігор під навантаженням, виявився добре придатним і для великих дата-центрів.
На базовому рівні планувальник процесора визначає, які програми, на яких ядрах процесора і в який момент виконуються. Стандартний планувальник Linux має працювати всюди – на телефонах, ноутбуках, настільних комп’ютерах і серверах, що робить його вкрай обережним і універсальним. Завдання Meta є принципово іншим. Компанія експлуатує надпотужні машини з сотнями ядер процесора, дуже різноманітними навантаженнями і, що найважливіше, жорсткими вимогами до затримок. У такому середовищі підхід «достатньо добре для всього» часто виявляється недостатнім. Замість створення окремого планувальника для кожного сервісу Meta прагнула отримати щось ближче до стандартного рішення для всього парку серверів, умовний «один варіант для більшості», який міг би автоматично адаптуватися без ручного налаштування. Саме тут і з’явився SCX-LAVD.
SCX-LAVD побудований на основі sched_ext, відносно нового фреймворку Linux, який дозволяє підключати альтернативні планувальники до ядра без суттєвих змін самого ядра. У спрощеному вигляді sched_ext дає змогу компаніям експериментувати з різними стратегіями планування без необхідності створювати власні форки Linux або підтримувати великі набори патчів. Абревіатура LAVD означає Latency-Aware Virtual Deadline, тобто «віртуальний дедлайн з урахуванням затримок». Назва досить точно описує принцип роботи. Замість використання статичних пріоритетів або ручних підказок планувальник постійно спостерігає за поведінкою завдань, за тим, як часто вони переходять у стан сну, прокидаються або блокуються, і на цій основі оцінює, які з них є чутливими до затримок. Таким завданням призначаються більш ранні «віртуальні дедлайни», що підвищує ймовірність їх швидкого виконання в умовах високого навантаження.
Початково такий підхід був продиктований потребами ігрових сценаріїв. На Steam Deck пропущені дедлайни планування означають втрату кадрів, ривки зображення або повільну реакцію на введення. У дата-центрах аналогічні проблеми проявляються у вигляді повільних веб-запитів, затримок доставки повідомлень або порушення цільових показників рівня сервісу. Застосування різні, але базова проблема однакова.
У своїй доповіді інженери Meta описали низку труднощів, які виникли під час масштабування LAVD до серверного обладнання. На системах із десятками ядер, що спільно використовують одну чергу планування, конкуренція за ресурси стала вузьким місцем. Закріплені завдання, тобто потоки, які можуть виконуватися лише на одному конкретному ядрі, створювали зайві перешкоди для інших процесів. Сервіси з інтенсивною мережевою активністю витрачали настільки багато часу на обробку переривань, що механізми обліку справедливості планувальника починали працювати некоректно.
Ці проблеми змусили змінити підходи LAVD до управління чергами завдань, часовими квантами і обліком використання процесорів. У кількох випадках Meta додала логіку для кращого збереження локальності кешу або для компенсації ядер, перевантажених мережевими перериваннями, фактично розглядаючи їх як «повільніші» процесори. Принципово важливо, що ці зміни не вимагали налаштування для кожного окремого сервісу або ручного призначення пріоритетів. Саме в цьому полягає ключова привабливість LAVD для Meta – адаптація відбувається на основі спостережуваної поведінки, а не жорстко заданих правил.
Окремо інженери торкнулися очевидного питання про те, чи не зашкодить оптимізація планувальника для серверів Meta його початковому ігровому сценарію використання. За їхніми словами, на поточному етапі зміни є нейтральними або навіть корисними для Steam Deck, а функції, які не мають відношення до ігрового середовища, можуть бути просто вимкнені за допомогою параметрів ядра. Водночас вони визнали, що експеримент триває і остаточні висновки ще попереду.
