PDS в какой ядре уже есть или патч надо накладывать?

Где сравнение с ванильным ядром?

Перетест делай - https://github.com/hamadmarri/cachy-sched

Это с ванильным и есть, CFS и твикованый CFS я на ванильном ядре проверял.

Я вручную накладывал, но для Arch есть, например, этот репозиторий.

Пока лень, но может потом и его проверю.

eli5 pls.

это означает что с PDS я могу на линуксе играть в Path of Exile с таким же FPS как и на венде?

А с ванильной десяточкой будет сравнение на том же железе? Учитывая что метрика сугубо утилитарная, по идее надо бы сравнить.

https://www.reddit.com/r/linux_gaming/comments/ho3xc3/os_optimization_does_gentoo_offer_better/

тут похожие детали обсуждались

Это означает что планировщик CPU, который в Linux используется по умолчанию, не очень хорош в играх, точнее в этой конкретной игре (Kingdom Come Deliverance) на моем железе. А с виндой я не сравнивал, там может быть лучше результат, а может и хуже.

Тем не менее, насчет Path of Exile, скорее всего FPS на линуксе будет плюс-минус таким же как на винде, так как в игру недавно завезли Vulkan рендер (но он вроде пока в Beta версии).

Мне хочется сравнить с виндой, но слишком лень ставить ее ради одной единственной цели, да и места на диске пока нет. Может и будет, но точно не в ближайшее время.

Нее, на моем томогочике можно играть на венде 60фпс спокойно даже в замесах (ну конечно когда уж слишком много мобов фпс падает), а вот на линуксе даже в средних замесах уже 40, такое ощущение что производительность где-то на 20% ниже.

• к тому же на линуксах Gnome Shell и KDE/Kwin это первые источники тормозов в играх, в каком-нибудь xfce такого нет даже с включенным композитором.

А что за железо? Если у тебя игра в проц упирается, то смена планировщика CPU может помочь. Попробуй твики CFS, благо ядро ради этого не нужно менять, даже перезагружаться не нужно:

echo 3000 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us 
echo 3000000 > /proc/sys/kernel/sched_latency_ns 
echo 300000 > /proc/sys/kernel/sched_min_granularity_ns 
echo 500000 > /proc/sys/kernel/sched_wakeup_granularity_ns 
echo 50000 > /proc/sys/kernel/sched_migration_cost_ns 
echo 128 > /proc/sys/kernel/sched_nr_migrate 

Если станет хуже, то просто перезагрузись, чтобы вернуть значения по умолчанию.

Это зависит от движка/порта, а не от линя. Достаточно сравнить порты AAA игр и dxvk.

Например Nier у меня выдаёт идентичный FPS на обеих ОС. А Wolfenstein: The Old Blood работает быстрее на лине. При этом «нативные» Borderlands 2, Tomb Raider 2013 и Bioshock Infinite вообще неработоспособны под линем. FPS раза в два ниже. На моих тестах Borderlands 2 через proton работает чуть лучше, чем нативный.

То есть если проц хороший, смысла от планировщиков ноль?

KDE/Kwin это первые источники тормозов в играх

kwin уже давно автоматически вырубает эффекты для fullscreen игр.

Ну, не совсем ноль, но с хорошим процем разница минимальна должна быть между планировщиками. Вот комментарий с reddit:

I also saw big improvements with PDS on an i5 6400 with various wine games. Upgraded to an 8700k and the difference is very small (even when CPU bottlenecked). So it does seem like low thread count CPUs can benefit a lot from a non-CFS scheduler.

Вот сравнение планировщиков на хорошем процессоре.

Но с другой стороны, есть и нагрузки, в которых сторонние планировщики дают улучшение даже и на хороших процессорах, опять же коммент с reddit:

It can also benefit heavy, threaded workloads like the RPCS3 emulator. Although it’s a fairly unique case, which particularly affects older Zen CPUs (that have inter-CCX bottlenecks).

I’ll add that MuQSS performs the best with this workload, and current PDS performs poorly.

У меня в играх нагрузка на проц от силы 20%. Поэтому сомневаюсь что имеет смысл менять планировщик (у мну gentoo, поэтому проще). Всё упирается в видяху, ибо 4к.

Да, в таком случае вряд ли стоит менять. В моем случае игра напрочь выжирает процессор, поэтому такая разница в бенчмарке.

Сейчас сижу с muQSS на старенькой двухголовой рабочей станции с NUMA архитектурой, два четырёхядерных Оптерона без гипертреда. Тестов никаких не проводил, шедулер накатил просто из любопытства. Органолептически никакой разницы с дефолтным шедулером не вижу, ни в играх, ни в работе, ни в конпелянии. Так что наверное когда буду ядро обновлять вернусь на дефолт. Справедливости ради ухудшений, оопсов и каких либо вообще странностей тоже никаких нет.

Я в большинстве случаев тоже разницы не вижу, прям сильно я заметил разницу считай только в Kingdom Come Deliverance, просто остальные игры у меня, как правило, не упираются в процессор.

Кстати, отключение Hyper-Threading у меня режет производительность на 20% в этой игре.

Вот, кстати, вопрос к опытным и мудрым. На новой станции два Ксеона о восьми ядрах каждый, с гипертредом получается 16 потоков на камень, итого в сумме 32 потока. Имеет ли смысл гипертред выключить вообще, чтобы он не смущал планировщик и не умножал число сущностей? Или тупо забить и оставить как есть. Машина занимается рендерингом видео, иногда на ней крутятся одновременно 3-5 виртуалок virtualbox, конпеляет, бывает сервером minecraft и ИГЫ1111.

Я бы на твоем месте забил и оставил как есть. Но я не особо мудр в этом вопросе, я только знаю, что у меня производительность лучше с ним чем без него.

Собираю обычно ядро с патчем от https://github.com/graysky2/kernel_gcc_patch
Плюс свой (делает доступной O3)

--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1232,7 +1232,6 @@
 
 config CC_OPTIMIZE_FOR_PERFORMANCE_O3
 	bool "Optimize more for performance (-O3)"
-	depends on ARC
 	help
 	  Choosing this option will pass "-O3" to your compiler to optimize
 	  the kernel yet more for performance.

Может надо было все патчи накладывать?

Я только PDS патч накладывал, остальные патчи не трогал. Правда, у меня ядро 5.4.

Результат: стало на 5 FPS меньше (по тесту Warthunder).

Ну, видимо на Warthunder отрицательно влияет. Если не лень снова пересобрать, можешь также попробовать MuQSS (0004-5.7-ck1.patch).

Результат: стало на 5 FPS меньше

Померил несколько раз, точный результат -0.5 FPS. Разницы в пределах погрешности.

У тебя же, насколько я помню, интеграшка, правильно? Скорее всего, у тебя в нее производительность упирается на любом из планировщиков.

Да, интеграшка.

Разница огромная

Огромная разница была бы если одноядерное поделие типа Gothic 4 Arcania пошло бы в 60 fps на чем-нибудь с множеством тухлых ядер, типа FX8120

типа FX8120

Бесполезно, никакой шедулер не сделает игровой процессор из бульдозера)

Кстати, а всяческие mitigations отключены?

Да, я их отключил.

Вот еще в Overwatch проверил производительность: https://flightlessmango.com/games/15751/logs/847

Тоже большой прирост от сторонних планировщиков.

У меня в играх нагрузка на проц от силы 20%.

Нагрузку надо по ядрам смотреть, она и с 20% может упираться в процессор.

Дошли руки и до Cachy. На моем железе он работает хуже чем стандартный CFS (по крайней мере, в Overwatch).

https://flightlessmango.com/games/15751/logs/986

Поправка, обновил бенчмарк. Оказалось, что Cachy у меня работает не хуже чем CFS. Точнее, при первом запуске игры - хуже, но при втором запуске - лучше. Тем не менее, все еще хуже чем MuQSS и PDS.

Видимо у Cachy какая-то проблема с I/O активностью, она почему-то значительно влияет на производительсть, поэтому при втором запуске игры производительность оказалась гораздо лучше.

Все шедулеры я тестировал в одинаковых условиях и замерял производительность при первом же запуске игры после перезагрузки системы, у других шедулеров нет проблемы с I/O. Для Cachy теперь пришлось сделать исключение и замерить производительность при втором запуске игры, когда уже все файлы игры закешировались.

Имеет ли смысл гипертред выключить вообще, чтобы он не смущал планировщик и не умножал число сущностей

Конечно. Заодно второй сокет и второй канал оперативки тоже выключи, чтобы они не смущали чипсет и не умножали количество сущностей.

А можно ещё весь компьютер в окно выкинуть, для абсолютного минимума сущностей.

почему именно эти значения, кто автор

Почему тема на лоре, а не на багтрекерах вайна и ядра?

Я их в патче TkG увидел, впрочем в ядрах Zen и Liquorix примерно такие же значения используются, можно в исходники глянуть.

Однако мне потом написали, что некоторые из этих значений удваиваются/утраиваются в зависимости от количества ядер процессора, а я это не учел, так что мои значения ниже чем должны быть.

Попробовал на ядре 4.0. Странно, этих параметров не существует, кроме самого первого.

# echo 3000 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us 
# echo 3000000 > /proc/sys/kernel/sched_latency_ns 
bash: /proc/sys/kernel/sched_latency_ns: Нет такого файла или каталога
# echo 300000 > /proc/sys/kernel/sched_min_granularity_ns 
bash: /proc/sys/kernel/sched_min_granularity_ns: Нет такого файла или каталога
# echo 500000 > /proc/sys/kernel/sched_wakeup_granularity_ns 
bash: /proc/sys/kernel/sched_wakeup_granularity_ns: Нет такого файла или каталога
# echo 50000 > /proc/sys/kernel/sched_migration_cost_ns 
bash: /proc/sys/kernel/sched_migration_cost_ns: Нет такого файла или каталога
# echo 128 > /proc/sys/kernel/sched_nr_migrate 
bash: /proc/sys/kernel/sched_nr_migrate: Нет такого файла или каталога

Видимо некоторые из них добавили в более новых версиях ядра.

Cachy теперь называется более подходяще для него - https://github.com/hamadmarri/cacule-cpu-scheduler

Автор, смотрю, с самоиронией)

Забавно) Я видел новое название, но не думал, что автор его в таком значении интерпретирует, он же вроде не русскоговорящий. Однако, судя по картинке, именно в таком.

Судя по всему, MuQSS и вообще весь патчсет ck больше не будут развиваться, так как автор потерял интерес. Печально, хороший патчсет.

https://ck-hack.blogspot.com/2021/08/514-and-future-of-muqss-and-ck-once.html

Всё что имеет начало, имеет и конец: Кон Коливас покидает разработку патчей для ядра