Поддержку добавили в дистрибутивное ядро, ничего делать уже не надо, всё уже включено по умолчанию
В этой статье рассказывается что такое hugepages, зачем они нужны, в чём преимущества и недостатки их использования, а так же даются инструкции по включению этой технологии в десктопном варианте ядра calculate-sources.
Предупреждаю, теоретическая часть даётся в “научно-популярном” виде, с упрощениями и обобщениями, подробности и детали желательно искать в Google, если возникнет такое желание.
Что такое hugepages
Как очевидно из перевода термина, hugepages - это большие страницы оперативной памяти. Для понимания отличия hugepages от “обычных” страниц придётся слегка углубиться в принципы выделения и работы с памятью процессорной архитектуры x86.
Традиционный 32битный процессор семейства x86 (x86-32) манипулирует страницами памяти размером в 4kb. Когда процессор выделяет память для какого либо процесса - он делает это маленькими кусочками, страницами, причём физически эти страницы могут быть разбросаны по всему ОЗУ. Для того чтобы не разыскивать каждый кусочек каждый раз отдельно, а адресовать сразу к большому куску состоящему из множества страниц, в процессоре существует специальный механизм TLB - буфер ассоциативной трансляции. Благодаря ему процессору не надо каждый раз вычислять где находятся нужные страницы, он обращается к этому буферу и с помощью специальной таблицы чрезвычайно быстро работает с этими разбросанными кусочками, как будто это один непрерывный кусок памяти.
И казалось бы всё хорошо, но хорошо ровно до тех пор пока у нас не переполняется буфер TLB, его размер физически ограничен, а оперативной памяти в компьютерах сейчас значительно больше, чем во времена старых 32битных систем. Как только буфер TLB переполняется быстродействие компьютера при работе с памятью падает, а память начинает сильно фрагментироваться. Если вы застали механические жёсткие диски и знаете что такое фрагментация файловой системы - вы приблизительно понимаете о чём я говорю (хотя это грубая аналогия, тема фрагментации оперативной памяти и её последствий академически глубока).
Для решения этой проблемы при переходе к 64битам в архитектуру x86 (x86-64) к традиционному механизму была добавлена технология для работы с “большими” страницами памяти, hugepages. “Большие страницы” могут иметь переменный размер, от 2mb до 1gb, что очевидным образом облегчает работу TLB, а так же уменьшает фрагментацию ОЗУ, так как по воле программиста память теперь может быть сразу выделена одним непрерывным куском желаемого размера. В результате производительность интенсивно использующих память программ существенно возрастает.
У этого подхода есть и свои недостатки. Если в программе есть ошибки приводящие к “утечке” памяти (непрерывному её выделению без последующего освобождения), последствия этой утечки со страницами размером в 1gb проявляются мгновенно и катастрофически, а с “классическими” 4kb страницами может пройти несколько часов, прежде чем закончится ОЗУ и система начнёт расходовать swap. Это самый очевидный недостаток, есть и другие, с которыми вы вряд ли столкнётесь не будучи программистами на языках с ручным управлением памятью. К счастью для нас, простых пользователей, “старый” механизм никто не отбирает, пользоваться им тоже не запрещает, к тому же использование transparent hugepages всегда можно отключить “на лету”, если происходит что то страшное и непонятное. Но оно уже давно не происходит, так как технологии больше десятка лет, и все кто желал ею пользоваться научились это делать.
Какие программы и программные технологии умеют пользоваться transparent hugepages и получают от этого прирост производительности
Вот неполный список того что может встретиться у вас на десктопе и заиграть “новыми красками”:
- Wine (в том числе Proton) и транслятор dxvk (DirectX в Vulcan), а значит и всё использующее это (Steam, Lutris, ну вы поняли уже мысль)
- Java и всё на ней написанное (Minecraft например)
- Технологии виртуализации KVM, XEN и всё на этом основанное (QEMU, Virtualbox)
- Базы данных PostgreSQL, MySQL
Как включить поддержку transparent hugepages
К сожалению в текущем десктопном конфиге ядра sys-kernel/calculate-sources transparent hugepages отключены полностью, бинарное ядро собирается без этой технологии, поэтому включить их “лёгким” способом через файловую систему конфигурации ядра /sys невозможно. Так что придётся переконфигурировать и пересобрать ядро.
Звучит страшно, но не бойтесь, мы не будем менять то что уже и так там есть, мы только добавим нужную технологию, и у нас появится возможность управлять ей, в том числе и полностью отключить, через файловую систему /sys, без перезагрузок, на лету. Calculate Linux имеет удобную утилиту для подобных манипуляций, кроме того, мы всё настроим так чтобы обновления текущего ядра 5.10 автоматически собирались и устанавливались без вашего участия, но с учётом внесённых нами изменений.
Возможны только два неудобства. Во первых ядро дистрибутива перестанет быть бинарным, а так как оно универсальное, для любых систем, и включает в себя и Солнце, и Небо, и даже Аллаха - процесс пересборки может занять некоторое значимое время. Если вы обладатель ультраслабого компьютера - весьма значимое. Слегка облегчить страдание поможет кэш компилятора ccache (emerge ccache). Прямо сейчас, при первой сборке, он ничего не изменит, но при выходе обновлений ядра слегка ускорит процесс. К счастью по умолчанию Calculate Linux живёт на LTS ядре (ядро долгой поддержки), а оно достаточно редко обновляется.
Во вторых, при выходе следующей версии LTS ядра процесс добавления галочек в конфиг придётся повторить. Правда есть надежда что после этой статьи поддержка transparent hugepages появится в конфиге “по умолчанию” и бинарное ядро будет приходить уже с ней. В этом случае статья устареет и надобность в ней отпадёт.
Давайте приступим собственно к процессу. Я буду подробно расписывать, объяснять и комментировать каждый шаг, чтобы вы не чувствовали себя испуганно и одиноко.
1. Меняем use флаги у пакета с ядром.
Нам обязательно нужно изменить два флага, третий флаг вы можете добавить дополнительно, по желанию, если захотите, их значения я объясню чуть ниже. Внимание, все действия выполняются в консоли root (это очевидно, но на всякий случай пусть будет предупреждение)
# echo "sys-kernel/calculate-sources vmlinuz -minimal fsync" >> /etc/portage/package.use/kernel
Этой командой мы создаём конфигурационный файл kernel с набором use флагов для пакета ядра. Если вы вдруг захотите всё вернуть “как было” - вам будет достаточно просто удалить его и переустановить ядро. И вы снова получите назад бинарное ядро собранное командой Calculate, а не вами.
Значения флагов: vmlinuz говорит portage что мы хотим автоматически собирать ядро каждый раз когда оно устанавливается или обновляется, -minimal означает что мы не хотим сокращённый набор исходников, - означает что мы отключаем этот флаг. (По умолчанию ядро приходит с урезанным набором исходников, достаточным для пересборки модулей, но не ядра целиком, это делается для экономии места и трафика. При использовании предварительно собранного ядра полный набор его исходников очевидно не нужен.) Флаг fsync заставит ядро собираться с предварительно включённым в него патчем от Valve ускоряющим работу игр в Steam Proton. Если вы не играете в игры через Steam или Lutris он вам не нужен, больше ничего в системе этот функционал не использует.
2. Получаем дерево исходных текстов ядра
# USE="-vmlinuz" emerge calculate-sources
Объявление переменной USE перед командой emerge нужно для временного отключения флага vmlinuz, так как мы хотим чтобы portage скачал и распаковал исходники не пытаясь при этом собирать из них ядро автоматически. Нам пока это не нужно, мы ещё не настроили конфиг ядра.
3. Настраиваем исходники
# cl-kernel -s
Ключ -s(–skip-build) говорит утилите cl-kernel не собирать ядро сразу после окончания настройки, мы сделаем это позже, нам некуда торопиться и нет необходимости собирать его два раза.
Перед вами появится псевдографический интерфейс настройки ядра. Выбирайте пункт Memory Management options, в нём пробелом поставьте звёздочку на пункте Transparent Hugepage Support. Убедитесь что в следующей строке сказано Transparent Hugepage Support sysfs defaults (madvise). Если там что либо иное - зайдите в это подменю и выберите madvise. Теперь сохраните конфиг (save) и выходите (exit), я надеюсь вы разберётесь как это сделать. Утилиты сами сформируют на базе этих изменений шаблон, который будет автоматически применяться при каждом обновлении ядра 5.10. Однако при смене минорной версии ядра придётся переключиться на него через eselect kernel (если это само не произойдёт автоматически) и повторить процесс настройки, так как шаблон сформируется только для ядер 5.10.XX, а не для 5.11.XX и так далее.
Что мы только что сделали. Мы включили прозрачную для ядра и программ поддержку hugepages и убедились в том, что по умолчанию она будет “правильно” настроена. В дальнейшем эту настройку можно будет изменить “на лету”, записав в файл /sys/kernel/mm/transparent_hugepage/enabled название одного из трёх режимов:
- none (очевидно, отключение технологии)
-
always (включение
hugepagesабсолютно для всех программ, размер страницы будет минимально возможный, 2mb. Red Hat использовала этот режим по умолчанию в своих дистрибутивах и вызвала много недовольства у системных администраторов, некоторые программы не знающие про существование transparent hugepages могут начать работать медленнее и давать повышенную нагрузку на процессор. Не включайте этот режим если не знаете зачем вы это делаете.) -
madvise (“умный” режим, использовать
hugepagesбудут только те программы которые умеют ими пользоваться и знают про системный вызовmadvise, наш вариант “по умолчанию”)
(не обязательно, но желательно) Обновляем микрокод процессора
Сейчас наступает чрезвычайно удобный этап для того чтобы обновить микрокод “правильным” способом (early boot update), зашив его в initramdisk, который нам сформируют утилиты при сборке и установке ядра. Зачем это делать? В процессорах тоже есть ошибки. Intel и AMD периодически выпускают обновления микрокода своих процессоров для их исправления. Обычно они входят в состав прошивки BIOS\UEFI, но как давно вы обновляли прошивку? А сколько лет вашей самой свежей прошивке? Не исключено что с этого времени вышла новая ревизия микрокода под ваш “камень”, так почему бы её не установить? Страшного ничего произойти не может, вы ничего не испортите, и если скачается та же версия микрокода что уже есть в BIOS - не страшно. Места микрокод занимает мало, грузится в процессор мгновенно, короче вы ничего не теряете.
Для процессоров AMD
# echo "sys-kernel/linux-firmware initramfs" >> /etc/portage/package.use/kernel
# emerge linux-firmware
Для процессоров Intel
# echo "sys-firmware/intel-microcode hostonly initramfs" >> /etc/portage/package.use/kernel
# emerge intel-microcode
Флаг hostonly говорит что мы хотим установить в систему микрокод только для того процессора что физически в наличии, а не для всех процессоров Intel во Вселенной. Второй флаг включает создание initramfs с этим микрокодом в /boot, утилиты потом сами его найдут и вошьют в родной initramdisk для ядра, автоматика всё сделает за нас. Сервера с архивами микрокодов медленные, так что если пакет ставится долго - это сервер медленно отдаёт, а не архив большой. За пару минут обязано скачаться.
4. Сборка ядра и установка
# emerge calculate-sources
# emerge @module-rebuild
# cl-setup-boot
Тут всё очевидно. Устанавливаем ядро, оно собирается у вас на машине со стандартным конфигом от бинарного ядра плюс сделанные выше настройки внесённые в конфиг сформированным cl-kernel шаблоном. Пересобираем модули. Перенастраиваем grub, чтобы initramdisk точно и гарантированно сформировался (это перестраховка, на всякий случай).
Перезагружаемся.
Благодарю за внимание.