BSDPORTAL.RU

Нет.

ну значит в один поток или еще что-то что снижает нагрузку на ядра...

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Не надо либастралить, пожалуйста. В 32 потока на 8 ядрах (которых 4, на самом деле).

Где-то я слышал (про баг 12309, кажется) что такие проблемы могут быть из-за кривого железа, контроллеров и мостов, видимо с какими-то глупыми очередями так что одна I/O операция блокирует всё (вплоть до USB, из-за чего дёргается мышь). Из-за этого же баг проявляется далеко не у всех, и софтом это лечится только диким throttling'ом, при котором производительность bulk I/O значительно падает, зато ничего не затывается.

Видео в HTML5 тормозит у меня и без дополнительной нагрузки.

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

ну кто таки решиться не либастралить, повторит в точности предложенное тут viewtopic.php?p=165183#p165183 для чистоты эксперимента и продемонстрирует результат на 2-х планировщиках - на своем текущем железе ?


мною проверено на 3-х разных железках (с разными процессорами чипсетами и материнками) на практике - ULE тормозит везде (в терминах интерактивности) и речь абсолютно не об I/O операциях - на них ULE сливает еще больше на всех 3-х железках.
напоминаю еще раз - мы говорим сугубо об интерактивности а не об аппаратных проблемах...

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Ну вот, если угодно: http://amdmi3.ru/files/scheduler.avi (снято с 60FPS для наглядности). Две сборки gcc в ncpu потоков каждая, 2 minerd'а, ваш ютуб ролик. Никаких nice/rtprio/idprio. ULE. Ничего не дёргается (хотя в теории это впритык, просто потому что firefox жрет ~4% CPU при проигрывании этого видео; если выполняемых потоков будет больше 100%/~4%, как ни крути, доля ff будет меньше нужных ему ~4%, он будет голодать и терять кадры. mplayer и всякая интерактивщина же, как правило, ничего не жрёт, так что с ней проблем не будет и при гораздо большем числе потоков).

да... для такого количества ядер на борту - думаю планировщик вообще не критичен...
через меня пока что 2 ноута прошло - оба на интеле (текущий Core i5 2410m) - и на обоих проблемы с подвисаниями при критичных нагрузках. видимо в мобильных процессорах что-то другое из внутренностей нежели в настольных... но в случае сабжа - эти подвисания менее сказываются
при ULE - видео воспроизводится мелкими рывками, если это будет заметно при 30fps, на FBFS -идет более плавно с редкими заметными подвисаниями.
при этом на ULE случаются моменты когда курсор мыши вообще фризится - на FBFS - такого не замечал...
sched FBFS
sched ULE

P.S. придется заменить звук - а то тыртуб возмущается по авторским правам главное что оригинальный звук ни там ни там не прерывается.

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Так на ноутах говноконтроллеры как раз и имеют наибольшую вероятность присутствовать. Что до ядер - так в i5 их всего в 2 раза меньше, а при том что нагрузка - что сборка, что miner, пропорциональна к-ву ядер, разницы нет. При этом можно и больше - пока я это пишу, mplayer играет Аватара в 1080p, в фоне 4 сборки по 8 потоков + 32 miner'а (т.е. ещё 256 потоков), LA 140 и растёт, и это никак не ощущается. А на работе тоже какой-то i5 (десктоп), и тоже сборки во много потоков на фоне процессов потребляющих чистый CPU, и тоже никаких неудобств (пока память не кончится).

Я думаю в вашем случае подвисания мыши показательны. Вы же знаете как работает шедулер - чем больше процесс спит, тем выше у него приоритет. Учитывая что Xorg'у чтобы пошевелить курсором нужны жалкие единицы тактов, он просто никак не может голодать по CPU. Дискового I/O он также не потребляет и ждать на нём не может. Остаётся не-дисковое I/O, например USB. Почему оно может тормозить столько времени что это заметно? Вероятно ждёт другого I/O, например диска (в голову не приходит других процессов, продолжающихся десятки-сотни миллисекунд; шедулинг всяко работает быстрее). А это уже либо железо, либо ядерные проблемы уровня драйверов PCI контроллера.

FBFS же тут если чем-то и помогает, то скорее всего неэффективностью в плане невозможности нагрузить и тем заткнуть это самое I/O. Оно может и выход в какой-то степени, но всё равно забивание гвоздей микроскопом и не повод для рекламы BFS как шедулера. Нужно разбираться что именно и в каком порядке летает по шине (наверное, копать в сторону dtrace для начала) и возможно изобретать какие-то механизмы троттлинга. Так, думается, можно прямым способом и более эффективно устранить эти проблемы с интерактивностью.

PS. -j для make в портах ни на что не влияет, влияет только переменная MAKE_JOBS_NUMBER, которая по умолчанию как раз равна hw.ncpu

Черт, мне бы так в ядре и шедулерах шарить.

Ну тут предположений не меньше чем знаний.

Давно хотел рассказать историю, да все забывал.

Сел я на Windows Server 2012 R2 компилировать KDevelop. А это значит весь Qt, добрую часть KDE Frameworks, все дела. На компе у меня Core i7-3770, 4х2 ядер, 16 гигов оперативки.

В процессе компиляции получил настолько сильные тормоза, что даже mp3 вконтакте (на флеше) играло с сильными запинками. Естественно, все остальные симптомы также присутствовали - залипающий курсор, задержка ввода с клавиатуры и т.д.

Я, признаться, совершенно не ожидал такого поворота, т.к. и железо нормальное, и шедулер (как я думал) эталонный. Быть может, здесь тоже проявились косяки, о которых говорил AMDmi3, однако я лишний раз убедился что ULE весьма и весьма неплох. На гораздо худшем железе (ноуте) при компиляции того же Qt он умудряется обеспечивать гораздо большую интерактивность, чем я видел на винде.

+1
Помимо винды, просто ради эксперимента я точно так же пробовал откомпилировать gcc под хакинтошем из MacPorts и под HAIKU.
Версии gcc естественно разные, но проводилось это всё на одном и том же железе.
И я был разочарован тоже в пресловутых и хваленых интерактивностях и Mac OS X, и HAIKU, как наследницы BeOS.
Хотя по тем же данным из желтой прессы под Mac OS X используется портированный ULE планировщик. Казалось бы...
А в HAIKU непонятно откуда планировщик, но точно не из BeOS (просто повторяющий по описаниям сохранившихся документаций к BeOS).

На FreeBSD - всё значительно лучше.

P.S. Кстати в Ubuntu тоже когда-то попытался собрать что-то из исходников, что потянуло за собой сборку gcc - тоже ощущения были не на высшем уровне. Но с того момента прошло уже достаточно времени - что-то могло измениться.

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

и насколько помнит мой склероз - я закрывал эту тему

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

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

К слову, безотносительно планировщиков, я бы не отказался от более гибкого управления приоритетами. Как минимум, nice не ограниченный 20, а лучше непривилегированный idprio.

а в чем проявляется нехватка диапазона -20 20?

всмысле?

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

0..20, потому что в минус - привилегированная операция. Нехватка, очевидно, в невозможности установить сколь угодно малый приоритет. Процесс с nice=0 против процесса с nice=20 получит ~80% времени, против 8 процессов с nice=20 уже ~30%. Я хочу такой nice чтобы процесс с nice=0 получал > 95% в обоих случаях.

idprio может выполнять только root. (fix: оказывается, уже есть sysctl чтобы разрешить его простому пользователю, но возможность дедлоков никуда не исчезает)

Видимо для начала нужно загнать kern.sched.interact в ноль, что бы получить абсолютно справедливое планирование от ULE наподобие поведения CFS в Linux.



Странно - дедлоки это обязательный фактор во всех ОС для таких же начальных условий?

я использовал иногда вот такой велосипед от root по крону:


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

_________________
Ми можемо все - що здатні собі уявити!
uname -a
Linux nonamehost 5.11.0-051100-generic #202102142330 SMP Sun Feb 14 23:33:21 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Не при чём здесь совершенно.


Дедлоки, насколько я помню, спутник любого невытесняющего шедулинга, и решают их внешними арбитрами. Во FreeBSD какой-то deadlock resolved есть, но я не знаю про это он или нет.


Смотреть на это больно. rtprio, вообще говоря, не только не гарантирует улучшения интерактивности (man rtprio, последний абзац), но и может её ухудшить, как по причине описанно в мане, так по той что когда вашему xfdesktop, например, захочется перерисовать иконки, видеоплеер, например, вообще не будет выполняться.