Разработчик игр Malte Skarupke опубликовал сравнение производительности блокировок на основе Mutex и Spinlock при использовании различных планировщиков задач. Тесты показали аномально большие задержки при использовании Spinlock с по умолчанию используемым в Linux планировщиком задач. Автор тестов сделал вывод, что планировщик задач Linux имеет проблемы, которые негативно сказываются на работе игр, создаваемых для сервиса Google Stadia, в котором игры выполняются на GPU в облачном окружении, а клиенту в потоковом режиме лишь транслируется содержимое экрана с частотой до 60 кадров в секунду. При подобных условиях необходимо обеспечить своевременный вывод кадров на экран и задержки превышающие миллисекунду становятся заметны...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52140
Ничего не понял из текста, но я более за Линуса. гугл в утиль.
*болею (извиняюсь, опечатка)
Выздоравливай 🤒
Спасибо, только насморк остался ещё
держи лекарство от Линуса - FuckUoyNvidia.png
Не забудьте специально для него заточенные салфетки Клинюкс
> Ничего не понял из текста, но я более за Линуса. гугл в
> утиль.Спинлок, грубо говоря, это пустой цикл, выполняемый с целью задержки. Если открыть руководство по разработке для ОС с "более простым планировщиком, чем в Linux" -- там такое можно найти в разделе "модули ядра" и с оговоркой про IRQL (нет смысла объяснять, что это -- для разработчиков игр оно неведомо).
Эммм, что за херню вы принесли и какие идиоты вас плюсанули??Цель спинлоков - не задержка выполнения программы, а быстрая проверка некоторого условия (например и чаще всего, захваченности мьютекса) в юзерспейсе без переключения в кернелспейс (которое довольно дорого по ресурсам).
Используется для снижения использования вычислительных ресурсов в случаях, когда ожидаются частые захват+освобождение того же мьютекса, например.
Любые программисты (не обезьяны, а программисты) в курсе что такое спинлок и нахера он нужен; даже на всех собеседованиях (на позицию программиста, а не обезьяны) об этом спрашивают.
> Эммм, что за херню вы принесли и какие идиоты вас плюсанули??
> Цель спинлоков - не задержка выполнения программы, а быстрая проверка некоторого условия
> (например и чаще всего, захваченности мьютекса) в юзерспейсе без переключения в
> кернелспейс (которое довольно дорого по ресурсам).Это называется побочный эффект (алгоритма). А кто не принимает во внимание, что сам алгорим -- тупой цикл -- тот потом и получает от Линуса советы.
> Используется для снижения использования вычислительных ресурсов в случаях
Да-да. Бывает, здорово снижает. Вместо пары переключений контекста -- мульён итераций у особо одарённых.)
> когда ожидаются
> частые захват+освобождение того же мьютекса, например.
> Любые программисты (не обезьяны, а программисты) в курсе что такое спинлок и
> нахера он нужен; даже на всех собеседованиях (на позицию программиста, а
> не обезьяны) об этом спрашивают.Спрашивающий, очевидно, от этого далёк, развёрнутое объяснгение лишь запутает, потому было заменено на оговорку "грубо говоря".
> сам алгорим -- тупой цикл(facepalm) Охохохохо...
Спинлок - это не тупой цикл. Это давно-давно, еще когда динозавры жили, придуманный примитив синхронизации, который в первую очередь требует эксклюзивного доступа к некоему ресурсу (обычно - ячейке памяти, обычно - lock на шину при доступе к ней) и который, уже во вторую очередь, является циклом (как и 99,999% любой компьютерной программы).
Причем, желательно, чтобы никаких итераций этого цикла не было вовсе. Спинлоки как раз используют тогда, когда ожидают, что ресурс будет в основном свободен. Вот в чем смысл спинлока, безграмотный аноним, а не в бездарном бегании по кругу.
> Да-да. Бывает, здорово снижает. Вместо пары переключений контекста -- мульён итераций у особо одарённых.)
Сдуру можно и буй сломать. Естественно, спинлоки надо правильно использовать - вы же не чистите зубы шариковой ручкой?
> Спрашивающий, очевидно, от этого далёк, развёрнутое объяснгение лишь запутает, потому было заменено на оговорку "грубо говоря".
Ваше "развернутое объяснение" оказалось совершенно ошибочным. Если вы сами не знаете предмета разговора, то лучше промолчать, чем вводить вопрошающего в заблуждение.
>[оверквотинг удален]
> (facepalm) Охохохохо...
> Спинлок - это не тупой цикл. Это давно-давно, еще когда динозавры жили,
> придуманный примитив синхронизации, который в первую очередь требует эксклюзивного доступа
> к некоему ресурсу (обычно - ячейке памяти, обычно - lock на
> шину при доступе к ней) и который, уже во вторую очередь,
> является циклом (как и 99,999% любой компьютерной программы).
> Причем, желательно, чтобы никаких итераций этого цикла не было вовсе. Спинлоки как
> раз используют тогда, когда ожидают, что ресурс будет в основном свободен.
> Вот в чем смысл спинлока, безграмотный аноним, а не в бездарном
> бегании по кругу.Я понимаю, что некоторые динозавры до сих пор не знают, что такое побочный эффект. Это собственно то, ради чего алгоритм, в данном случае - тупой цикл без полезной работы, выполняется. Случается, что таких эффектов несколько. В данном случае эффектом оказался вовсе не тот, о котором ты с таким апломбом написал. Такой вот наблюдаемый результат.
>> Да-да. Бывает, здорово снижает. Вместо пары переключений контекста -- мульён итераций у особо одарённых.)
> Сдуру можно и буй сломать. Естественно, спинлоки надо правильно использовать - вы
> же не чистите зубы шариковой ручкой?Ну вот сломал один. Линус ему объясняет, в чём дело. Тебе ситуация из новости ни о чём не говорит? Мне очевидно, что ты мог бы всё это адресовать тому критику Линукса, было бы больше пользы. Он ведь тоже думает, что у него там "вот счас быстренько проверим свободный ресурс".
>> Спрашивающий, очевидно, от этого далёк, развёрнутое объяснгение лишь запутает, потому было заменено на оговорку "грубо говоря".
> Ваше "развернутое объяснение" оказалось совершенно ошибочным. Если вы сами не знаете предмета
> разговора, то лучше промолчать, чем вводить вопрошающего в заблуждение.Хочешь сказать, что я напрасно сделал оговорку "грубо говоря", после того как сам же и потратил столько времени на её развёртывание?)))
Стоит уточнить/усугубить, что в linux (в современной glibc) mutex'ы реализованы через futex'ы aka benaphor'ы.Суть же фьютекса в том, что это просто word в userspace, над которым выполняются interlocked/atomic операции с syscall'ом в slow-path.
Соответственно, если такой мьютекст свободен и его никто не ждет, то стоимость его захвата/освобождения такая-же как у spinlock'а. Сискол же будет когда потребуется ожидание при захвате, или для пробуждения других процессов при освобождении.
>>Цель спинлоков - не задержка выполнения программы, а быстрая проверка некоторого условия (например и чаще всего, захваченности мьютекса) в юзерспейсе без переключения в кернелспейс (которое довольно дорого по ресурсам).ИМХО это просто костыль оставшийся от лени делать программные прерывания. Асинхронность можно сделать и без вызова ядра.
Захваченности чего? Mutex нельзя захватить. Это просто сигнализирующий механизм. Вывеска на двери номера "Сейчас я трахаю Машу. Дырка занята, заходите позже".
Захватить это и есть вывесить вывеску на пустую дверь. Кто первый тот и папа.Другое дело, что смешались в кучу кони, люди...
Один из способов захвата и называется спинлок.
Ага, ну да, конечно, у Штадии проблемы из-за плохого планировщика в линуксе, а совсем не из-за сетевой задержки. Да-да...
Из такого вольного пересказа Я бы тоже ничего не понял. Читайте ответ Линуса в оригинале.Вкратце, чувак сам не понял, что он измеряет.
Ага. Мне особенно приглянулись вот эти кусочки:> And then you write a blog-post blamings others, not understanding
> that it's your incorrect code that is garbage, and is giving random
> garbage values.Прям почти старый добрый Линус :-)
> I repeat: do not use spinlocks in user space, unless you actually
> know what you're doing. And be aware that the likelihood that you
> know what you are doing is basically nil....и доходчивое разъяснение "на пальцах", почему именно.
> (Pretty much every time we picked an unfair - but fast - locking
> model in the kernel, we ended up regretting it eventually, and had
> to add fairness).А вот об этом лет двадцать назад говорили солярочники -- мол, это ваш пингвин быстрый, пока не умеет кучу процессоров; а как обрастёт fine grained locking -- так и остепенится.
И ещё про particularly bad random number generator, угу. :)
PS: интересно, индусы успеют захавать гугль?
Уже)
В руководстве американских корпораций сплошные Лингамапутры с цыганскими методами.
> "на пальцах"На скольких и на каких?
Старый Суровый Линус, я бы сказал )
> Ничего не понялне понял - не пиши сюда.
"Вы просто неправильно их используете!"
всё очевидно же: очередной смyзихлёб в зауженных тениках прострелил себе ногу (не разбираясь досконально в теме) и кричит простреленную ногу "р3шето"
"Я ничего не понял, но я за Торвальдса". Кичишься своим невежеством, и ещё +50 себе накрутил? Вот чудак. А тем временем, в комментариях есть хорошие комменты, например о том, что автор сервера JACK отписался в комментах, а также толковый коммент с обзором шедулёров в Windows.
> А тем временем, в комментариях
> есть хорошие комменты, например о том, что автор сервера JACK отписался
> в комментах, а также толковый коммент с обзором шедулёров в Windows.а чего ж ссылки то не дали?
А что тут непонятного-то? Разработчики игр и околоигровая братия считают, что Линус должен немедленно начать оптимизировать ОС под специфические игровые задачи, особенно когда некоторые компании вроде Гугл собирались зарабатывать на этом большие деньги. Линус ответил, что не одними играми мир мазан.
>Ничего не понял из текста, но я более за Линуса. гугл в утиль.Мужик!
Я нихера не понял, что ты сказал мне, но ты мне близок.
Ты заговорил, и достучался до сердца.
(Джей и Молчаливый Боб Наносят ответный удар)Это и называется фанатизмом: следование решению партии без вникания в суть.
Линус Торвальдс опустил диванного эксперта
Линусу или пора опять в отпуск, подумать над своим поведением , или он обратно отрастил свои стальные CoC`и ? =D
Линусу повезло, что "эксперт" не трансвестит или что-то вроде.
Захочет отомстить — сменит. Gamergate v2.0 пока что не исключён.
Ой ли.
Реально жесть! Смотреть до конца!
Как будто игроиндустрии бывают какие-то другие.
Опять выгораживает Инго Молнара, как и 10 лет назад. Всё-таки неудивительно, что Финляндия когда-то была частью России: у Линуса явно есть принцип "да, он конечно не прав - но он же СВОЙ, а СВОЕГО надо защищать любой ценой". Думаю, вы часто наблюдали такое в нашей странеВопрос знатокам: как там MyQSS?
> Опять выгораживает Инго Молнара, как и 10 лет назад. Всё-таки неудивительно, что
> Финляндия когда-то была частью России: у Линуса явно есть принцип "да,
> он конечно не прав - но он же СВОЙ, а СВОЕГО
> надо защищать любой ценой". Думаю, вы часто наблюдали такое в нашей
> странеЯ тебя разочарую, но эта(точнее похожая) фраза была сказана(и стала 'крылатой') американцем.
> Вопрос знатокам: как там MyQSS?В оригинальном англоязычном посте дан ответ. В первом же абзаце пишут, что с ним тоже плохо.
Хм, неожиданно. Много лет использую spin lock-и в местах, где lock очень короткий и получаю прирост в производительности, как и в синтетических тестах, так и по метрикам production-а. А тут, выясняется, что сам Линус говорит, что spin lock-и использовать нельзя.
> Хм, неожиданно. Много лет использую spin lock-и в местах,
> где lock очень
> короткийВажная деталь.
> сам Линус
> говорит, что spin lock-и использовать нельзя."использовать с большой осторожностью и полностью разбираясь в деталях"
>> сам Линус
>> говорит, что spin lock-и использовать нельзя.
>
> "использовать с большой осторожностью и полностью разбираясь в деталях"Если быть конкретнее, то Линус говорит:
> Or, if you really want to use use spinlocks (hint: you don't), make sure that while you hold the lock, you're not getting scheduled away. You need to use a realtime scheduler for that
То есть с его точки зрения, я всё это время использовал spinlock-и неправильно. И я не говорю, что Линус не прав. Я лишь говорю, что это неожиданно (и является пищей для размышления). Хотя, мне всё же кажется, что область применения spinlock-ов шире, чем обозначил Линус, ибо успех на коротких lock-ах много раз переподтверждался на разных платформах (если они не одноядерные) и без realtime scheduling-а. То есть да, есть риск, что scheduler переключит поток, в котором я собирался разблокировать spin lock, но если lock достаточно короткий, то такое бывает очень редко, и в среднем будет (и есть) сильный выигрыш. Не очень понимаю, почему Линус так сказал...
> то такое бывает очень редкоИз-за этого редко некоторые игры на Stadia лагают, поэтому Линус ему так и ответил что он **** и не разбирается в том, как работает spinlock на ОС без realtime scheduling-а. Вот и весь посыл, а ещё он сказал что всё что намерил разработчик - мусор. И правильно сказал, ибо в контексте, в котором пишет разработчик Stadia, оно мусором и является.
а разве мерил разработчик стадии? там вроде какой-то левый чувак вобще..
> я всё это время использовал spinlock-и неправильноНе так что бы всё. Точнее можно оценить из соотношения времён взятия спинлока и длительности кванта планировщика.
> и является пищей для размышления
ИМХО именно с такой целью Линус и высказался.
Это примерно как в детстве учат: "не суй пальцы в розетку". Потом преподают закон Ома и так далее. Кто-то идёт в электрики, кто-то -- атомные электростанции строить. А некоторым и к старости нечего пальцы в розетку сувать.
> Это примерно как в детстве учат: "не суй пальцы в розетку".Ой да. Единственно что дополню: по упорным типа меня лучше работало "сунешь пальцы в розетку -- долбанёт так, что мало не покажется". Чтоб когда всё-таки долбанёт, было над чем задуматься и попробовать выяснить, а они-то откуда заранее знали...
То есть от неоправданных догматов переходить к пониманию происходящего.
PS: а то розетка-то может быть обесточенной, "догмат" пострадает (и в следующий раз может не спасти своего носителя), поскольку был неверен изначально -- а понимание подскажет, почему пронесло.
Миша, ты на праздниках перебрал, что-ли? Уносит тебя куда-то не туда...
Иду я и вижу: человек дотронулся до трансформаторной будки, его бьёт током. Среагировал как положено, подручным предметом из диэлектрика разомкнул цепь.--
Попал мне камушек в сандаль. Я рукой об эту штуку опёрся, ногой потряс, и тут этот ошалелый меня как огреет доской!
>в детстве учат: "не суй пальцы в розетку"А я сунул. Точнее за оголенные провода специально взялся. Нехило так потом руку колотило.
это говорит о том что вы не до конца понимаете как работает спинлок, но вам повезло и вы не получили от этого негативных последствий( либо не заметили их)
Правильный быстрый lock должен быть как критические секции в винде. В случае промаха захвата ресурса нужно уйти ждать объект ядра, предварительно поставив флаг заставляющий при освобождении ресурса отправить уведомление ядру. В таком случае при переключении контекста блокировавшего потока(если уж случилось) ожидающие этот же ресурс потоки не будут мешать блокирующему ресурс потоку вернуться к выполнению. То есть займёт меньше времени.
"Вы просто неправильно их используете!"
> Много лет использую spin lock-и в местах, где lock очень короткий и получаю прирост в производительности, как и в синтетических тестах, так и по метрикам production-а.На коротких спинлоках статистически ты выигрываешь. Но изредка возможны (относительно большие) задержки, в тех случаях, когда твой спинлок был прерван перепланировкой. Тебя это устраивает, а игроделов - нет.
А ещё он говорил что обычный юзер имеет право менять системное время на хосте...много чего он говорил.
в php коде ?
Имхо костыль. Что конкретно Вы этим костыляете - сказать затрудняюсь, но я бы не назвал это нормальной практикой.
Тогда на всякий напомню его же подобное по стилю разъяснение о том, почему PAE использовать не надо совсем вообще никогда нигде, а системам с более чем гигабайтом (даже не двумя) памяти показана 64-битная адресация: http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-abo.../
> Тогда на всякий напомню его же подобное по стилю разъяснение о том,
> почему PAE использовать не надо совсем вообще никогда нигде, а системам
> с более чем гигабайтом (даже не двумя) памяти показана 64-битная адресация:
> http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-abo.../Эта статья вызывает мегатонны фейспалмов и показывает, что бестолковость Торвальдса лишь немного меньше бестолковости среднего опеннетовского анонима.
А разве где-то память через PAE реально использовалась? Самый реальный пример который мне опадался - сторонний драйвер RAM-диска который был способен организовывать диск в PAE области. Так чсебе применение, но всеж таки. В куда большем числе случаев PAE включался просто чтобы использовать NX-бит.
В том же Oracle RDBMS в стародавние времена в качестве кеша. И прочих программах которым нужно было много памяти.
На текущий момент при выборе новой системы - действительно не актуально.
> Хм, неожиданно. Много лет использую spin lock-и в местах, где lock очень
> короткий и получаю прирост в производительности, как и в синтетических тестах,
> так и по метрикам production-а. А тут, выясняется, что сам Линус
> говорит, что spin lock-и использовать нельзя.Строго говоря, Линус говорит, что их ненужно использовать, если вы точно не знаете как надо, чтобы было не больно, а то будет ай-ай-ай!
> прирост в производительностиThis. У него "прирост производительности" aka "Average test duration" на спинлоках в линуксе тоже виден, почти на всех шедулерах. Но его же интересует задержка, aka "Four longest idle times" - что даже не 99 перцентиль.
Если чувака интересует только задержка, что из переписки не очевидно, то он явно пользуется спинлоками неправильно.
Политика SCHED_OTHER ему не подходит в таком случае, для этого есть SCHED_FIFO.
>Если чувака интересует только задержка,А всякие starvation и проблемы с перегруженным процессором его не колеблют, то да чем проще цикл spinlock - тем эффективней. Если рояет что-то другое, то и инструмент надо выбирать другой.
Вообще-то он про другое говорит. В основном про методику измерения времени задержки, которая показывает, что иногда, при вытесняющей многозадачности, случаются моменты окончания выделенного кванта времени. И сравнивать скорость захвата, по тому где в коде это происходит дело не благодарное.
Если на MuQSS не будет провала (а я подозреваю что это так), то прав совсем не Линус
По такой же логике можно обвинить компилятор, если программа не работает, когда на самом деле она не работает из-за UB (мол "на другом-то компиляторе всё good!").
Челюсть ставишь, что без спинлоков на CFS будет быстрее? Или просто так ляпнул, авось за умного сойти?
> Челюсть ставишь, что без спинлоков на CFS будет быстрее? Или просто так
> ляпнул, авось за умного сойти?Это ты челюсть поставил вот этой заявой и предположениям выше про MuQSS. Так что ждём от тебя результатов и сорцов для повторения тестов (ты ведь не будешь подгонять цифирки, просто -- так принято).
Поздравляю, Шарик, ты балбес. Иди чекни статью по оп ссылке
Тебе надо, ты и иди. Заодно челюсть спасёшь.
Я предпочитаю просто обсуждать вопрос в плоскости логики и/или ссылок на факты. "Челюсть" не буду "ставить" в любой дискуссии.
Тут сразу вспоминается история с memcpy(), glibc и adobe flash
> Тут сразу вспоминается история с memcpy(), glibc и adobe flashа что там было?
я так понимаю, имеется в виду вот это: https://www.linux.org.ru/news/linux-general/5545961
Сложно сказать, как в этом случае. Возможно в данном случае Линус прав: не понимаешь что это и как его правильно использовать - не используй. С memcpy(), имхо, он был не прав, причём по аналогичной логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся безопасным и более медленным memmove()-ом.
Нет. В тот раз проблема была в навязывании всем: "Есть дураки, которые не понимают чем memcpy() отличается от memmove(), поэтому давайте будем считать дураками всех и отберём memcpy() у ВСЕХ"
> Нет. В тот раз проблема была в навязывании всем: "Есть дураки, которые
> не понимают чем memcpy() отличается от memmove(), поэтому давайте будем считать
> дураками всех и отберём memcpy() у ВСЕХ"Ну так, к сожалению, Линус такое и предлагает в https://bugzilla.redhat.com/show_bug.cgi?id=638477#c101
I'd personally suggest that glibc just alias memcpy() to memmove().
И в этом я с ним не согласен.
А я что написал?..
> А я что написал?..Прошу прощения, значит я неправильно понял Ваш посыл.
> Сложно сказать, как в этом случае. Возможно в данном случае Линус прав:
> не понимаешь что это и как его правильно использовать - не
> используй. С memcpy(), имхо, он был не прав, причём по аналогичной
> логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся
> безопасным и более медленным memmove()-ом.Прошу прощения за свою лень, напишу, не смотря в исходники. В упомянутых функциях уже столько проверок, что ещё одна мало что изменит.
>> Сложно сказать, как в этом случае. Возможно в данном случае Линус прав:
>> не понимаешь что это и как его правильно использовать - не
>> используй. С memcpy(), имхо, он был не прав, причём по аналогичной
>> логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся
>> безопасным и более медленным memmove()-ом.
> Прошу прощения за свою лень, напишу, не смотря в исходники. В упомянутых
> функциях уже столько проверок, что ещё одна мало что изменит.простая, но оптимизированная для x86, memcpy() выглядит так:
;------------------X8
void *memcpy(void *d, void const *s, size_t n)
{
__asm__ __volatile__(
"rep ; movsl\n"
"movl %1,%%ecx\n"
"andl $3,%%ecx\n"
"jz 1f\n"
"rep ; movsb\n"
"1:"
:
:"c"(n / 4), "g"(n), "S"(s), "D"(d)
:"memory"
);return d;
}
;------------------X8
а memmove() - так:
;------------------X8
void *memmove(void *d, const void *s, size_t n)
{
__asm__ __volatile__(
"cmpl %%esi,%%edi\n"
"jb 1f\n"
"addl %1,%%edi\n"
"addl %1,%%esi\n"
"decl %%edi\n"
"decl %%esi\n"
"std\n"
"1:"
"rep ; movsl\n"
"movl %1,%%ecx\n"
"andl $3,%%ecx\n"
"jz 2f\n"
"rep ; movsb\n"
"2:\n"
"cld"
:
:"c"(n / 4), "g"(n), "S"(s), "D"(d)
:"memory"
);
return d;
}
;------------------X8
как можете видеть, разница таки есть. как минимум в анализе перекрытия областей и прочей математики, для обеспечения копирования "назад".
> простая"I'd personally suggest that glibc just alias memcpy() to memmove()."
В glibc она не такая простая, насколько помню, там есть выбор от размера копируемых данных. А если добавить проверку перекрытия в простой код: на больших объёмах не играет роли; на малых memcpy() не эффективна.
>> простая
> "I'd personally suggest that glibc just alias memcpy() to memmove()."
> В glibc она не такая простая, насколько помню, там есть выбор от
> размера копируемых данных. А если добавить проверку перекрытия в простой код:
> на больших объёмах не играет роли; на малых memcpy() не эффективна.Не могу с Вами, как и с Линусом, согласиться. На малых и известных на этапе компиляции объёмах, при соответствующем уровне оптимизации, gcc может заменить memcpy() на свой код, который копирует как memcpy() (разворачивается в последовательность команд mov). По крайней мере я такое точно наблюдал в своих проектах. На больших объёмах - да, лишние потери будут меньше, но всё-равно будут. А если это какой-нибудь там Intel Atom с тактовой частотой 400MHz? Не везде можно, и оправдано, ставить самый распоследний 32-х ядерный, или какой там сейчас самый топовый, Intel Xeon с сотнями гигабайт памяти ОЗУ.
>>> простая
>> "I'd personally suggest that glibc just alias memcpy() to memmove()."
>> В glibc она не такая простая, насколько помню, там есть выбор от
>> размера копируемых данных. А если добавить проверку перекрытия в простой код:
>> на больших объёмах не играет роли; на малых memcpy() не эффективна.
> Не могу с Вами, как и с Линусом, согласиться. На малых и
> известных на этапе компиляции объёмах, при соответствующем уровне оптимизации, gcc может
> заменить memcpy() на свой код, который копирует как memcpy() (разворачивается в
> последовательность команд mov). По крайней мере я такое точно наблюдал в
> своих проектах.Тоже наблюдал такое и очень давно. Именно это и имел ввиду, когда писал что сама функция не эффективна (это и обуславливает инлайн mov). В таком случае замена не должна играть роли, поскольку аналогичная оптимизация происходит и с memmove(), и с ручным (в смысле, в цикле) копированием.
> На больших объёмах - да, лишние потери будут меньше,
> но всё-равно будут. А если это какой-нибудь там Intel Atom с
> тактовой частотой 400MHz? Не везде можно, и оправдано, ставить самый распоследний
> 32-х ядерный, или какой там сейчас самый топовый, Intel Xeon с
> сотнями гигабайт памяти ОЗУ.Пенальти на неверно предсказанный переход, навскидку, тактов 10-20, а вот скорость копирования упирается в ширину пропускания шины памяти, которая поуже чем у кеша, то есть процессор часть времени в любом случае как бы простаивает. Ну и если проверок несколько, значит и пенальти при неверном предсказании потенциально и так есть.
С моей точки зрения такое объединение нежелательно по другой причине: поощряет пофигизм при написании кода и нарушает переносимость на другие ОС и libc.
> С моей точки зрения такое объединение нежелательно по другой причине: поощряет пофигизм
> при написании кода и нарушает переносимость на другие ОС и libc.Тоже думал про такой аспект, но забыл написать.
Независимо от результатов с muqss, это не противоречит словам Линуса, просто потому что этот планировщик как раз неуниверсален и разрабатывается исключительно для десктоп систем. Есть мир за пределами рача на твоём ноутбуке
Где-то тут должна была быть логика, но она не обнаружена. Зачем мне планировщик, который не оптимизирован под мои задачи, на моём ноутбуке? Для понтов?
а кто сказал что он не оптимизирован?
зыж
и да — кто не обнаружил логику?
Он переоптимизирован настолько сильно, что стал работать медленнее? Ок
враньё
Поддерживаю. В чем смысл одного универсального, но менее эффективного планировщика? Легче сопровождать? Лень?
Ну, собственно ничего нового. Линуксу фиолетово на десктоп, ясень пень.
> Поддерживаю. В чем смысл одного универсального, но менее эффективного планировщика? Легче сопровождать? Лень?А какие ОС нынче имеют несколько специализированных планировщиков, не просветите?
> Где-то тут должна была быть логика, но она не обнаружена. Зачем мне планировщик, который не оптимизирован под мои задачи, на моём ноутбуке? Для понтов?Не хочу вас расстраивать, но под персонально ваши задачи не будут оптимизировать свой планировщик ни в одной из существующих операционных систем.
Поэтому извольте давиться тем, что дают.
>Зачем мне планировщик, который не оптимизирован под мои задачи, на моём ноутбуке? Для понтов?
>Где-то тут должна была быть логика, но она не обнаружена.А ты забавный. Понтов дофига и прям все тебе должны. Мы тебя прощаем, пакуйся с миром.
Виндовый планировщик прекрасно отрабатывает как в серверной, так и в десктопной части.
Фрюшный планировщик прекрасно отрабатывает как в серверной, так и в десктопной части.
И только в б-жественном линуксе из-за "универсальности" планировщик толком не справляется ни с серверной, ни с десктопной частью.
> Виндовый …
> Фрюшный …И тут же все вместе, включая набрасывающего на вентилятор, тут же отправились в пешее… догонять топ500
И что top500? Там серверная аль десктопная нагрузка?
> И что top500? Там серверная аль десктопная нагрузка?Там ещё более другая, скорее пакетная. Ну, если учонные опять не этсамое...
т.е. наполовину:
> как в серверной, так и в десктопной части.ты уже соврал.
теперь хочешь чтобы поймали и на второй?
А знаешь почему Джо неуловимый? :D
Алкоголь - зло.
> Если на MuQSSЭто тот, который в idle грузит все ядра на 30-50%?
Спасибо, ешьте сами.
Линус технично опустил Гуглоеба. Молодец товарищ Торвальдс.
Неа, он просто, как всегда, отмазался, чтоб не признавать что на протяжении десяток лет они были неправы (претензии к планировщику были задолго до этого теста).
Я не поддерживаю комментарий выше по поводу "молодец, опустил", однако всё же:Можно конкретнее про претензии к планировщику и какое они имеют отношение к данному тесту?
Я не спец, поэтому вместо ссылок на технические детали дам ссылку на неприятную историю. По ссылкам ниже - история разработки разработчика-любителя:https://www.linux.org.ru/news/linux-general/2042898
https://www.linux.org.ru/news/linux-general/4044309
> ссылку на неприятную историюЕсть программист-любитель по имени Кон Коливас, для которого это не основная работа. Когда он писал свои первые программы на языке Си, то сообщество Open Source ему помогало, указая на ошибки, и это помогло ему со временем отточить свои навыки программирования. Со временем, он начинал писать хорошо, и переходил на новый, более сложный уровень, где всё повторялось.
Кон являлся сторонником использования Linux на десктопе, и начал отправлять патчи в ядро, улучшающие отзывчивость системы на десктопе. По логике, со временем его патчи должны были принимать активнее, ведь со временем он улучшал навыки программирования, и начинал писать код всё лучше. Так и происходило, но в какой-то момент его патчи перестали принимать вообще.
Я не знаю точной причины, и могу лишь предполагать. Может, это личная неприязнь: "а кто он такой? Вот мы - дипломированные спецы, выпускники Гарварда и MIT, а он кто?". Возможно что Кон был импульсивным и неприятным в общении, и разработчики ядра просто не могли терпеть ещё одного такого. Возможно, что Игно боялся увольнения и назначения вместо него Кона, если его планировщик всё-таки примут в ядро.
Планировщик Кона предназначался для десктопов, и был направлен на рост отзывчивости в ущерб производительности. Сначала его не приняли, направив на доработку, указав на ошибки в коде. Потом ошибки были исправлены. но разработчики ядра нашли новые - уже не такие явные. Потом ошибки кончились, и тогда Инго сказал, что 'fair scheduling' "не нyжeн". Мол, выгода от этого планировщика субъективна, и её невозможно померить в цифрах. Тогда попросили добавить его как опцию, и возможность выбора планировщика в make menuconfig, как это сделано для планировщика ввода/вывода. Но тут уже сам Торвальдс сказал, что по его мнению, это нe нyжно.
Несколько последующих лет, ситуация напоминала цирк. Кон бодался с разработчиками ядра, пытаясь протолкнуть в апстрим свои патчи, уже отполированные к этому моменту до блеска. Те придумывали красивые причины для отказа в приёме патчей. Юзеры над ситуацией потешались, а для популярных дистрибутивов Linux (таких как Ubuntu 6.06) были готовые сборки ядра с новым планировщиком (-ck (для Linux 2.4, -ck2 для Linux 2.6).
Всё закончилось тем, что Инго Молнар написал планировщик CFS. Это был 'fair scheduling' планировщик - такой же, как -ck2. https://lwn.net/Articles/230501/ Приятно, что Инго не стал замалчивать вклад Коливаса, а поблагодарил его за то, что он его убедил в полезности 'fair scheduling'.
Коливас заявил, что CFS повторяет его планировщик, просто написан полностью "с нуля" и без оглядки на его код. Так было некрасиво поступать. И тем не менее, теперь а апстриме есть 'fair scheduling' планировщик, а значит, Коливас больше не нужен. И он принял решение уйти из разработки ядра.
Спустя 2 года он вернулся, выпустив BFS. BFS это пропатченный CFS для большей отзывчивости на десктопе. Она по-идее и так должна была быть хорошей, но Коливас заметил, что CFS имеет проблемы. В первые годы, BFS жёг напалмом, но впоследствие работу CFS подтянули до уровня BFS. Сейчас Коливас разрабатывает MyQSS
Сильно напоминает историю с reiser4
Это не то, что напоминает - это ситуация 1:1 и даже еще более стремна. Там хотя бы покривили носы, но сделали что-то аналогичное, а в случае с reiser разработку забанили, потому что, видите ли, файлуха не должна лезть в управление томами, но при этом протащили в апстрим btrfs по настоятельной просьбе оракла.
Ничего общего. Reiser4 не в ядре просто потому, что единственный разработчик — Шишкин — в этом не заинтересован. Он делал прототип для демонстрации научных тезисов, разработка рабочего решения его не интересует.
До того, как Шишкин стал маинтейнером, там было много разрабов,
и о включении reiser4 в ядро их упрашивали 3 года - с 2004-го по 2006-йИнтересно получается: Reiser4, которая прекрасно чинит разделы - не рабочая,
а Btrfs, которая не может этого сделать, оказывается, рабочая...
Возможно, но после ухода Рейзера только Шишкин и светился. Кроме него из основных разработчтков нет.
Потому что с Шишкиным работать, мягко говоря, тяжко. Убедить его, что проблема на стороне его чудо-подeлки и её надо решать, гораздо сложнее, чем того же Торвальдса.
> Интересно получается: Reiser4, которая прекрасно чинит разделы - не рабочая, а Btrfs, которая не может этого сделать, оказывается, рабочая...Обе могут починить, а могут и не починить. С некоторой вероятностью.
А лучше всего ext4 и (с недавних пор) XFS, которые не ломаются сами по себе.
Это XFS-то не ломается сама по себе… Ох, сколько мы с ней наелись, вроде недавно в ней баги правили, может больше не будет разваливаться.
Он-то как раз очень заинтересован в том, чтобы протолкнуть проект в ядро и набрать проекту популярности и разработчиков, но после того, как он несколько раз обращался в core team и его столько же раз послали, он забил на дуболомов и пилит reiserfs в сторонке.Человек подходит к вопросу с академической точки зрения, а не как это обычно в ляликсе "тяп-ляп - и в продакшн, проблемы будем решать потом". И когда такое кощунство видят ляликс-разрабы, они говорят "это прототип". Потому что матан - для лохов, а крутые перцы знают лучший рецепт - надо купить комп мощнее.
> Он-то как раз очень заинтересован в том, чтобы протолкнуть проект в ядро и набрать проекту популярности и разработчиковВ сотрудничестве он не очень заинтересован. Тем более — с программистами, а не учёными.
> но после того, как он несколько раз обращался в core team и его столько же раз послали
> Человек подходит к вопросу с академической точки зренияИменно из-за его "академической точки зрения": "Проблемы? Какие проблемы? УМВР. Если у вас что-то не работает, чините сами".
Шокирующие откровения от человека, который пытался помогать Шишкину: https://www.linux.org.ru/news/linux-general/15445203?cid=154...> А вообще я про то, например, что в какой-то момент мы запретили миграцию страниц для страничного кэша reiser4, потому что «ниработаит», а искать проблему и чинить её — да кому это нужно?
Академичность Шишкина не может не вызывать уважения.
Спасибо, интересно, как изменилось мнение. Возможно, мы даже увидим весьма интересную Reiser 6, когда intelfx залечит набитые шишки, переосмыслит детали и ради шутки назовёт так свою ФС.
Наоборот, он был заинтересован в том, чтобы протолкнуть файлуху в ядро, но столкнулся с людьми, которые при слове "алгоритм" делают круглые глаза и смотрят непонимающим взглядом, а решения принимают на основании не нужности или полезности, а на основании приближенности к телу решателей.Причем, reiser зарубили даже не из-за проблем (которых у тех же BtrFS/XFS ничуть не меньше), а потому что нельзя файлухе лезть в управление томами, бо есть LVM. Когда впиливали BtrFS - глазки на собственные правила (непонятно только кем сформулированные) закрыли, а как поступило предложение впилить reiser - все вдруг сразу стали коре тимо облико морале.
> Сильно напоминает историю с reiser4Ага. И Шишкин, и Коливас имеют некоторые проблемы социального плана, мешающие им полноценно участвовать в разработке в составе крупного коллектива.
Вот из-за этого "человеческого фактора" мы никогда не увидим я ядре ни BFS, ни Reiser4.Только не надо выставлять их жертвами. Жертвы — скорее те, кому приходится с ними работать.
одна лирика, ни одной ссылки на тест.
если bfq так жёг, то чего его автор его закопал? а, так там не было масштабируемости на больших системах, регресс. то то злые мейнтейнеры не хотели его в апстрим
Да хлам он был. Даже я на чисто хомячковых задачах типа скопировать файл 1гб с ссд на хдд ловил полный лок гуя на минуту (видимо это именно то что называют 12309 судя по симптомам), причём любыми другими планировщиками чего угодно повторить не удавалось. Поэтому надо гнать ссаными тряпками, а не иделизировать дилетантов.
Хотя у меня тоже был эффект плацебо в стиле "вроде как отзывчевей переключение стало". Когда столкнулся с проблемами как-то попустило, в конце концов лучше разбросать nice приоритеты по процессам и под нагрузкой всё ок с отзывчивостью и так.
Коливас не программист, а анестазиолог. Вот и подросла школота которая не знает истории.По сути, Торвальдс в очередной раз облажался. Нельзя сделать щедулер который будет вов сех сценариях самым лучшим. Для дестопа нужен один тип щедулера с низкими задержками, для сервера другой где главное пропускная способность. Если аппликуха в один момент времени сильно нагружает диски, а в следующее мнгновение нагружает проц на 100% на миллисекунду то шаттный щедулер Linux не сможет подобрать правильный план выполнения поскольку он подбарет его на основе прошлой статистике поведение, а это поведение будет говорить что это приложение нагружает диски, а не проц.
Что касается bfq, то это было просто эксплутирование частоты перектлючений, если в штатном ядре оно плавает от 300 до 1000 переключений в секунду, то Коливас поднял до 10000 fix. Надо ли говорить, что это полная херня?
Есть подобные истории из *BSD систем?
> Есть подобные истории из *BSD систем?"Не беда, что своя корова сдохла! Плохо, что соседская жива!" (с) народный аноним
Я не с целью высмеивания, а правда интересно, для сравнения.
> Есть подобные истории из *BSD систем?Тео де Раадт со своим пиаром убер-безопасного рeшета затмевает всю эту мышиную возню =)
> Всё закончилось тем, что Инго Молнар написал планировщик CFS. Это был 'fair scheduling' планировщик - такой же, как -ck2. Приятно, что Инго не стал замалчивать вклад Коливаса, а поблагодарил его за то, что он его убедил в полезности 'fair scheduling'.
> Коливас заявил, что CFS повторяет его планировщик, просто написан полностью "с нуля" и без оглядки на его код. Так было некрасиво поступать. И тем не менее, теперь а апстриме есть 'fair scheduling' планировщик, а значит, Коливас больше не нужен. И он принял решение уйти из разработки ядра.Если верить анонимам, утверждающим, что 12309 внесён именно CFS, получается, "благодарить" за этот баг нужно не сколько Молнара, сколько Коливаса?
Ппц. Одна ссылка ведёт на страницу, где написано "AdBlock detected, а ну отключай его". Вторая в конечном итоге уводит на страницу, где требуется регистрация. Действительно, неприятная история. Какой-то анально-огороженный разработчик любитель.
Это ссылки 07 и 09 годов. Арзив интернета в помощь
А, вот почему ссылки исходно ведут на lor. Понятно. Лор как замена букмаркам браузера -- оригинально.
> Это ссылки 07 и 09 годов. Арзив интернета в помощьОфигенно, учитывая, что текущий планировщик в проде где-то с 2010 года.
> https://www.linux.org.ru/news/linux-general/2042898
> https://www.linux.org.ru/news/linux-general/4044309Ты сам-то эти страницы смотрел? В первой ссылка http://apcmag.com/6735/interview_con_kolivas перекидывает на страницу с предложение подписаться на этот apcmag, во второй чья-то жежешечка, для просмотра которой надо иметь учётку в ЖЖ, потому что просмотр только залогиненным лжеюзерам.
А ты думал? Претензии к CFS есть, просто они секретные. Лучше не показывать их технически грамотным людям.
Вот один чувак выкатил претензии к CFS в паблик — и его сразу уделал некто Торвальдс.
> он просто, как всегда, отмазался, чтоб не признавать что на протяжении десяток лет они были неправытаки да - 12309 всё ещё случается.
Очень сильно подтверждаю.
Линус сказал что так универсальнее. И заодно что так работает. Но не сказал что в конкретной задаче так лучше.
вантузный игродел решил попрграмировать под линукс и публично опозорился
> Автор теста попытался возразить Линусуахахаха, спорить с родителем самой linux-системы
лучше бы он этого не делал
Автором планировщика для ядра Linux (что самого первого O(1), что второго, CFS) был Инго Молнар, Первый планировщик был хороший, но не идеальный, второй планировщик был ещё хуже. И когда пользователи стали жаловаться на баг 12309, вызванный переходом на CFS в ядре 2.6.23, Линус заявил, что это "совокупность багов, которые действуют в сумме, и эти баги трудно выловить по-одному и устранить". На самом деле, в более ранних версиях ядра (например 2.6.16) бага 12309 не было вообще, а его появление как-то чудесно совпало с появлением нового планировщика.Альтернативные планировщики в ядро не принимались. Тоже озвучили какую-то благоприятную причину, а истинную, стыдную, не озвучили
Другое дело, оффтопик. Вызвал timeBeginPeriod() и всё стало плавно. Правда, в документации к функции написаны странные вещи. :)
> На самом деле, в более ранних
> версиях ядра (например 2.6.16)
> бага 12309 не было вообще, а его
> появление как-то чудесно совпало с
> появлением нового планировщикаИ только разработчики с 10+ лет стажа сейчас тяжело вздохнули ибо знают, что ситуация, когда исправляешь один баг, и тут же всплывает пяток других, которые не были видны из-за первого бага, случаются очень часто.
> И только разработчики с 10+ лет стажа сейчас тяжело вздохнули ибо знаютибо знают cfs шедулер это про Фому, а cfq шедулер — про Ерёму
первый — process scheduler https://www.kernel.org/doc/html/latest/scheduler/sched-desig...
второй — io scheduler https://www.kernel.org/doc/Documentation/block/cfq-iosched.txtзыж
но что характерно, что 10 лет назад, что сейчас путают их между собой одни и те же "школьники"
https://www.linux.org.ru/news/linux-general/2042898?cid=2045250
> И когда пользователи стали жаловаться на баг 12309 ........есть планировщик задач, а есть планировщик ввода-вывода.
во-о-о-т...
наводящий вопрос - как ты думаешь о каком из них лет 10 назад спорили дяди пока ты прогуливался школу?
баг 12309 вызван проблемами в чипсете intel вышедшем в то время, на amd как вы можете знать этот баг не воспроизводился.
> ахахаха, спорить с родителем самой linux-системы
> лучше бы он этого не делалПочему же лучше? Человек, в результате, получил обратную связь от Торвальдса. Если он не прекратит свои изыскания, но учтёт результаты беседы с Торвальдсом и продолжит исследования ещё месяца два, он будет понимать в применении спинлоков в играх столько, сколько мало кто понимает. Причём, при желании, у него есть опция написать более вдумчивую статью, сравнивающую спинлоки и мьютексы, и продолжить беседу с Торвальдсом. Вероятно, узнав ещё что-нибудь, из не лежащего на поверхности.
А что, спорить с ним нельзя?Можешьне отвечать, я уже понял что ты сектант.
Нет. Не потому что Линус прав, а потому что спорить с ним нельзя. О том и новость.
> Нет. Не потому что Линус прав, а потому что спорить с ним нельзя.
> О том и новость.Ещё один чукча-писатель.
Новость о том, что блокировки -- это сложно. И с кондачка начинать негоже. Сперва -- тропарик :) (в данном случае изучение уже наработанного и осознание предметной области)
Еще можно придумать заголовок что у Линуса новая должность капитан очевидность. Его основной довод что так уже работает и так универсальные ну и он в этом прав. А чувак который на него наезжает говорит что может быть лучше как минимум в некоторых случаях что какбэ тоже уже тянет на помощника капитана.
> А что, спорить с ним нельзя?Не стоит спорить с людьми, которые умнее и грамотнее тебя в предметной области.
>> А что, спорить с ним нельзя?
> Не стоит спорить с людьми, которые умнее и грамотнее тебя
> в предметной области.А вот разговаривать -- стоит. Скорее с "почему" и "зачем", по опыту.
От того что Линус грамотнее меня в своей предметной области игрушка шустрее работать не станет.как нет т не будет массового десктопа под ним. Одни фрикции устаревшего ещё при рождении ядра.
В общем виде:
Игроделы заточились под вынь.
Тупой порт на другие платформы дает тупой результат.
Какие претензии ко второй платформе?
Претензии к игроделам
Претензия ко второй платформе проста:она пытается уметь все. А когда указывт на косяки фанатики говорят что это фичи, как например в темах о линуксовом управлении памятью
Формально да, Линус в этом споре прав.
А ненадо всё валить в кучу, планировшик и vm это разные вещи.
> А ненадо всё валить в кучу, планировшик и vm это разные вещи.Вот и не надо мешать задачи сервака, суперкомпа и десктопа, прикрываясь фиговым листом универсальности.
Вторая платформа если уж решила быть комбайном могла бы подумать про качество работы в некоторых задачах. Или признать что не шмогла.
> В общем виде:
> Игроделы заточились под вынь.В таком случае они бы использовали критические секции, а не велосипед.
> Тупой порт на другие платформы дает тупой результат.
> Какие претензии ко второй платформе?
> Претензии к игроделамКогда они игры играли, а не писали, timeBeginPeriod() по документации не имела отношения к планировщику и считалась хаком.
Ну Windows спасет только мощное железоА даже на старом хламе вполне норм линукс работает
А игры на Ютубе вполне проходятся
А как тогда вытащить из них то, чем они умнее и грамотнее? Иного приходится привселюдно неучем обозвать, чтобы он раскрылся и выдал что-то по существу. Понимаю, что это, в общем-то, разновидность троллинга, не самое лучшее дело для кармы, но приходится иногда и к таким методам прибегать.
>А как тогда вытащить из них то, чем они умнее и грамотнее?Методика паразита. Учиться не пробовал? Помогает.
Кон Коливас смотрит на эту дискуссию, как на битву нанайских мальчиков
http://ck-hack.blogspot.com/2020/01/happy-new-decade.html
MuQSS support cgroups, but not all the cgroup features (e.g. CPU limiting will not work).Кону Коливасу пофек.
Забавно читать про "более простые планировщики". Знания внутренностей ядра Windows типичного Linux-апологета видимо ограничивается уровнем Windows XP/слитых исходников Win2000. В каждой версии Windows планировщик значительно усложнялся: Vista - динамическое изменение кол-ва ядер и поддержка гипервизоров, 7 - начальная поддержка NUMA нод (вплоть до 256 ядер), 8 - ноды с различными характеристиками (мощность, производительность), поддержка до 1280 ядер, новые механизмы для синхронизации (WaitOnAddress), 8.1 - рефакторинг, больше очередей для разных видов ожидания потоков, больше механизмов для синхронизации (да, включая аналог futex), 10 RTM - ещё больше рефакторинга, 10 (2019) - поддержка сложного неравенства ядер (как в Threadripper), 10 (2020) - потоки могут менять идеальное ядро (ядро выполнения) в любой момент, если это даст выигрыш по производительности.
Нужно просто признать, что планировщики Linux и Windows затачиваются для разного. Linux комфортно себя чувствует в датацентрах на приложениях высокого качества кода (написанного профессионалами), либо на кофеварках (да, на тех, на которых ещё Hadoop крутится). Windows же нацелен на работу на домашних ПК либо на серверах до 1000 (1280 если быть точнее) ядер, где должны хорошо работать приложения, написанные любым программистом, на любом хипстерском ЯП (Go, JS, ...) и не очень (C, C++, ...).
Где почитать более свежие исходники ядра Windows? Дайте адрес на GitHub
Нигде. Проприетарщина. Тут Linux впереди планеты всей. Лишь бы работал хорошо. Исходный пост не про то, что Linux плох, а про то, что он не для тех задач и условий, для которых создавался Windows.
ну и нафига тогда этот спич выше про вантуз, если сабж — цитата:
> … игр, создаваемых для сервиса Google Stadia, в котором игры выполняются на GPU в облачном окружении?
очевидно вантузный шедулер тут не применим
Спич про Windows к содержимому ответа Linus'а, и некоторой части коментаторов в mailing list'е и здесь. В Google Stadia - вероятно не применим. Но ведь оригинальная статья упоминает Google Stadia лишь как начальный толчок к исследованию. А часть комментаторов просто начинает кидать гнилые помидоры в сторону Windows, не разбираясь толком ни в том, ни в другом.
про затмения на Марсе — тоже очень интересная тема.
при этом они также ничего не меняют (и не добавляют) к сабжу вообще и к содержимому ответа Linus'а в частности
> про затмения на Марсе — тоже очень интересная тема.Интересная наверное тема, да.
> при этом они также ничего не меняют (и не добавляют) к сабжу вообще и к содержимому ответа Linus'а в частности
> Yes, it turns out that certain simple schedulers get exactly the behavior you want.Как по мне, так это Linus про планировщик Windows. И про его простоту.
А если открыть Reddit, и почитать мнение диванных экспертов, так вообще интересно становится. Тут уже приводили статью про волшебную пилюлю 1usmus с весьма спорными, вплоть до некорректности, утверждениями, так на Reddit'е ровно те же слова, прямо копипаста, но рекомендуют другую пилюлю. Так что утверждение про примитивность очередного компонента ядра Windows начинает играть иными красками (вплоть до аксиомы в религиозном учении).Я не утверждаю, что Linus Torvalds некомпетентен (ибо сам я не обладаю достаточным уровнем знаний в Linux ядре, мелкое админство и порт userspace приложений с Win32 не даёт такого уровня знаний). Но я отмечаю, что некоторые утверждения, сделанные ещё в районе середины 00-х (если не раньше), превратились в мире СПО в своеобразный постулат, который, на самом деле, устарел. Проприетарный код развивается не хуже свободного, а про это иногда забывают.
M$ предоставляет исходники своей продукции включая Windows всех версий в ФСБ, иначе не смогла бы продавать на территории РФ.
МС предоставляет бабки, а не исходники.
Кстати,
> иначе не смогла бы продавать на территории РФ.Неправда. Сертификация ФСТЭК нужна только для госзакупок в организации, работающие с гостайной.
Продавать системы с предустановленной ОС в обычных магазинах можно без сертификатов, сотни разных андроидов не дадут соврать.
>Неправда. Сертификация ФСТЭК нужна только для госзакупок в организации, работающие с гостайной.Нет, для закупок винды в госучреждения код винды должен был быть предоставлен ФСБ для изучения и он был предоставлен. Гугол в помощь.
Что забавно, этот код ещё в бородатые 90-е (на рубеже 99-2000 если не ошибась или на пару лет позже) везли из аэропорта (куда код прилетел из США) на инкасаторском броневике. Даже в новостях показывали репортаж.
И гугл как раз скажет, что сертификаты нужны для аттестации, а аттестовать нужно лишь определённые системы. Либо обрабатывающие тонны ПДн, либо работающие с гос. тайной и т.п. Более того, обычно достаточно ФСТЭК-овских сертификатов.
Windows Internals 7th edition
https://www.techpowerup.com/review/1usmus-custom-power-plan-.../Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it.
В линуксе вот этот момент гораздо правильней реализован
Угу. Процитирую эту статью:> Windows considers a core as "busy" even if there is only a single thread using it and moves that same thread to an idle core if one is available!
Ну, во первых, термина "busy" в планировщике Windows вообще нет (есть только его противоположность, idle). Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит. Советую почитать Windows Internals, например 7-ое издание. Там и терминология соответствующая, и материал соответствующий Windows 10 района 2016 года (например, там всё ещё Stride, а не StrideMask в KPRCB, т.е. нововведения для поддержки новых Ryzen там не покрыты).
> Furthermore, the Windows process scheduler makes no distinction whatsoever between physical and virtual cores, nor between CCXes with their separate caches.
Как минимум Windows 8 и выше прекрасно в курсе HT/SMT и в самом планировщике. Даже Windows 7 старалась сдвигать работу на физические ядра. Про детали CCX ничего не знаю, поэтому утверждать не буду.
> Just to clarify: the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware.
Это неверно как следствие первых двух ошибок.
В этой же статье далее рассказывается про их power plan, который делает "всё правильно". Но ничего не упоминается даже про то, что Microsoft дропает поддержку кастомных планов, и что на достаточно современных планшетах и ноутбуках всего один, новый, динамический план питания. Что весьма странно и, в совокупности с фактическими ошибками, не вызывает доверия к их экспертному мнению.
Возможно (даже вероятно) планировщик в Linux сложнее, способен обрабатывать даже очень невероятные ситуации. Я лишь утверждаю, что планировщик в Windows тоже неплох, да ещё и развивается.
> Угу. Процитирую эту статью:
>> Windows considers a core as "busy" even if there is only a single thread using it and moves that same thread to an idle core if one is available!
> Ну, во первых, термина "busy" в планировщике Windows вообще нет (есть только
> его противоположность, idle).Ну как бы ядро (т.е. исполнитель) и тред (контекст исполнения, в т.ч. адрес исполняемого кода) и есть "противоположности".
; set context swap busy for the idle thread and acquire the PRCB Lock.
;mov rdi, PbIdleThread[rbx] ; get idle thread address
ifndef NT_UP
mov byte ptr ThSwapBusy[rdi], 1 ; set context swap busy
https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/amd64/...> Во вторых, смена процессора выполнения потока "просто потому
> что появилось idle ядро" никогда не происходит.
; The new thread is the Idle thread (same as old thread). This can happen
; rarely when a thread scheduled for this processor is made unable to run
; on this processor. As this processor has again been marked idle, other
; processors may unconditionally assign new threads to this processor.
https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/amd64/...Интересно было бы поискать это "unconditionally" условие, но я не делал утверждения "никогда не происходит".)
Люблю когда по делу переписка.По первому куску кода WRK:
Не знаю, зачем сюда уже подмешивать механизм context swap, который чаще всего выполняется в конце работы планировщика.По второму куску кода WRK:
К чему он вообще? Он отвечает за завершение итерации idle loop, когда новый поток выполнения не найден, или найден, но на него переключиться нельзя (по разным причинам, например изменение affinity после перехода в standby режим потока).
Unconditionally - это скорее подчёркивает, что поскольку этот поток ничего полезного не делает (только спиннит ядро в ожидании работы), то никаких дополнительных условий при выборе ядра для нового потока в очереди выполнения проверять не надо.> Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит.
Я пишу про то, что поток, выполнявшийся на одном ядре, без очень весомой причины (до сборки 19536, в ней это стало происходить чаще благодаря новому Cache Aware Scheduling) не станет выполняться на другом ядре, т.к. Ideal processor чаще всего остаётся неизменным в thread lifecycle.
Ну и в целом, приводить в пример урезанное ядро Windows XP - скучно. Реверс Windows 10 - совсем иные ощущения.
Зато я нашёл ошибку в своём начальном посте: Stride - свойство KNODE конечно, а не KPRCB (ноды, а не конкретного ядра).
> Люблю когда по делу переписка.Э, нет, дружище, я тут не весть какой помощник. Мне это было интересно, когда сорцы WRK доступны не были.
> По первому куску кода WRK:
> Не знаю, зачем сюда уже подмешивать механизм context swap, который чаще всего
> выполняется в конце работы планировщика.Не читал первую ссылку, но исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил. Из вышеприведённого или подобного куска. Ссылка на KiIdleLoop - намёк на казалось бы просто вопрос "на каком IRQL выполняется спящий поток?", которым можно много кого завалить.
> По второму куску кода WRK:
> К чему он вообще? Он отвечает за завершение итерации idle loop, когда
> новый поток выполнения не найден, или найден, но на него переключиться
> нельзя (по разным причинам, например изменение affinity после перехода в standby
> режим потока).
> Unconditionally - это скорее подчёркивает, что поскольку этот поток ничего полезного не
> делает (только спиннит ядро в ожидании работы), то никаких дополнительных условий
> при выборе ядра для нового потока в очереди выполнения проверять не
> надо.К "просто потому что появилось idle ядро", которую каждый понял по-своему. Тут как раз "swap from idle to idle".
>> Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит.
> Я пишу про то, что поток, выполнявшийся на одном ядре, без очень
> весомой причины (до сборки 19536, в ней это стало происходить чаще
> благодаря новому Cache Aware Scheduling) не станет выполняться на другом ядре,
> т.к. Ideal processor чаще всего остаётся неизменным в thread lifecycle.К примеру, у нас 2 ядра и 4 потока. 2 выполняются на одном ядре, 2 на другом. Первые 2 завершились. Это весомая причина? Понятно, что должно быть перераспределение.
> Ну и в целом, приводить в пример урезанное ядро Windows XP -
> скучно. Реверс Windows 10 - совсем иные ощущения.Представляю, какие были ощущения у online-solutions.ru
когда MS выкатило очередной подарок. :)> Зато я нашёл ошибку в своём начальном посте: Stride - свойство KNODE
> конечно, а не KPRCB (ноды, а не конкретного ядра).А что, сейчас такие вещи нигде толком не обсуждаются?
> исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил.Вероятнее всего. Вопрос - понимает ли автор, что стоит за этим словом?
> на каком IRQL выполняется спящий поток?
Да, занятный, но я бы на него ответил контрвопросом "в какой-то конкретный момент или в целом?". Но вообще это наверное для проверки на вшивость разработчика драйверов, нежели ради реальных знаний.
> Понятно, что должно быть перераспределение.
Да, но оно не* результат перераспределения как такового, а, например, результат поиска работы того же idle thread. Но Ideal процессор то не менялся.
> Представляю, какие были ощущения у online-solutions.ru
> когда MS выкатило очередной подарок.Кто это? Никогда о них не слышал. Вот у настоящих производителей антивирусных пакетов я думаю неплохо так горит от каждого обновления Windows, ибо их любимый хардкод и хаки начинают рассыпаться (и вводить в BSoD/GSoD или приводить к ошибке обновления до новой версии).
> А что, сейчас такие вещи нигде толком не обсуждаются?
Есть любители поковырять ядро, но обычно знания остаются у расковырявшего. Увы.
>> исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил.
> Вероятнее всего. Вопрос - понимает ли автор, что стоит за этим словом?Он относит busy к ядру процессора, которое в принципе не может быть idle (но может находиться в HALT state).
>> на каком IRQL выполняется спящий поток?
> Да, занятный, но я бы на него ответил контрвопросом "в какой-то конкретный
> момент или в целом?". Но вообще это наверное для проверки на
> вшивость разработчика драйверов, нежели ради реальных знаний.Это к пониманию работы механизма переключения контекстов выполнения (а это только планировщик, но и диспетчер).
>> Понятно, что должно быть перераспределение.
> Да, но оно не* результат перераспределения как такового, а, например, результат поиска
> работы того же idle thread. Но Ideal процессор то не менялся.
>> Представляю, какие были ощущения у online-solutions.ru
>> когда MS выкатило очередной подарок.
> Кто это? Никогда о них не слышал. Вот у настоящих производителей антивирусных
> пакетов я думаю неплохо так горит от каждого обновления Windows, ибо
> их любимый хардкод и хаки начинают рассыпаться (и вводить в BSoD/GSoD
> или приводить к ошибке обновления до новой версии).Споров организовал в своё время. Их OSAM тогда сразу же обогнал AutoRuns. Основной продукт был с серьёзным замахом, но так и не выпустили, поскольку MS кислород перекрыли.
> Реверс Windows 10 - совсем иные ощущения.Ну и что там внутри, мой анонимный брат?
Гора неочевидного кода, твой анонимный брат. Неочевидного - потому что ты не знаешь настоящей причины, зачем он там. А ведь он нужен.Ах да, это же прямо как исходники Linux, с патчсетами от крупных компаний-производителей процессоров, спеки то всё равно только они имеют. Конец минутки неудачной иронии.
> Гора неочевидного кода, твой анонимный брат. Неочевидного - потому что ты не
> знаешь настоящей причины, зачем он там. А ведь он нужен.Ох уж эти индусы…
> Ах да, это же прямо как исходники Linux, с патчсетами от крупных
> компаний-производителей процессоров, спеки то всё равно только они имеют. Конец минутки
> неудачной иронии.«Это свобода!» — говорили они нам лет около двадцати назад.
Хочу уточнить: твои придирки, как я понял, относятся не к фактической части, а к теоретической? То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро, тебя не устраивает то, как эти перекидывания объясняются, так?
> То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро,Я утверждаю, что их нет (до введения Cache Aware Scheduling пару недель назад).
> тебя не устраивает то, как эти перекидывания объясняются, так?
Меня не устраивают неверные утверждения про то что современный планировщик Windows не в курсе про SMT/HT/NUMA/архитектуру Ryzen, или что он имеет всего одну глобальную очередь потоков на выполнение (или даже что он имеет одну локальную для ядра очередь потоков). А следовательно - про его простоту.
>> То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро,
> Я утверждаю, что их нет (до введения Cache Aware Scheduling пару недель
> назад).В смысле, они были до введения Cache Aware Scheduling пару недель назад, я правильно понял? Статья от ноября 2019 года. То есть она всё говорит правильно.
Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений, вывести противоположное утверждение? НЕ было. Так ясно?
В статье лажа не по этой причине, а из-за следующих двух параграфов с голословными заявлениями (и противоречащим реалиям, если посмотреть код или почитать авторитетные источники вроде Windows Internals), ставящих под сомнение всё их экспертное мнение.
Где это такое видано чтобы оба сабжевых оратора были не правы? Либо черное либо белое. Либо один прав, либо другой, третьего не дано. Таков путь.
> Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений,
> вывести противоположное утверждение?Как можно писать, что я читаю одно твоё сообщение за другим, и до сих пор продолжаю уточнять, что именно ты имеешь в виду?
> НЕ было. Так ясно?
Нет, не ясно. Чего именно не было? Те графики в статье показывающие как поток выполенения перепрыгивает с ядра на ядро -- туфта нарисованная в фотошопе?
> В статье лажа не по этой причине,
"Не по этой" -- это не по какой? Я простите не телепат, чтобы угадывать, на что именно ты ссылаешься всеми этими своими местоимениями.
> они были до введения Cache Aware Scheduling пару недель назад
> НЕ было. Так ясно?
> Нет, не ясно. Чего именно не было?:/ Поток перепрыгивает с ядра на ядро не по причине "планировщик неоправданно переключить ядро", как в начальном вопросе:
> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
А по причине того, что ядро освобождается, и ищет работу. Оно находит работу в очереди у другого ядра (если повезёт - в той же ноде или ноде с теми же характеристиками). Оно обрабатывает её, вместо простоя. Где ненужность?
> "Не по этой" -- это не по какой?
Не по тобою же обозначенной в первом же твоём сообщении (и статье).
> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
> Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it.А реальная лажа в статье в утверждениях:
> Furthermore, the Windows process scheduler makes no distinction whatsoever between physical and virtual cores, nor between CCXes with their separate caches.
Планировщик Windows знает про HT. Про CCX я не знаю, ничего утверждать не буду.
> the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware.
Планировщик Windows тоже знает про SMT.
> Linux handles this rather better: it actively prefers to keep threads on the same core for as long as there are no scheduling conflicts on that core.
Планировщик Windows тоже предпочитает оставлять потоки на последнем ядре выполнения. Но может и сменить.
>> они были до введения Cache Aware Scheduling пару недель назад
>> НЕ было. Так ясно?
>> Нет, не ясно. Чего именно не было?
> :/ Поток перепрыгивает с ядра на ядро не по причине "планировщик неоправданно
> переключить ядро", как в начальном вопросе:
>> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
> А по причине того, что ядро освобождается, и ищет работу. Оно находит
> работу в очереди у другого ядра (если повезёт - в той
> же ноде или ноде с теми же характеристиками). Оно обрабатывает её,
> вместо простоя. Где ненужность?В перекидывании потока: за ним ведь приходится тянуть все кеши. Какая разница планировщику какие ядра будут простаивать без работы? Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное? Что от этого изменится в лучшую сторону?
Ничего в лучшую сторону не изменится, а вот накладные расходы будут. Значит перекидывания ненужные.
>> "Не по этой" -- это не по какой?
> Не по тобою же обозначенной в первом же твоём сообщении (и статье).
>> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
>> Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it.Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе? На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
Если графики не были нарисованы в фотошопе, то вот тогда у меня появится следующий вопрос: как эти графики можно объяснить, не прибегая к словам "ненужные перекидывания потоков", "dumb Windows scheduler" и тому подобных?
> А реальная лажа в статье в утверждениях:
Я отмечу, что ты не предлагаешь никакой альтернативы им. Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
> В перекидывании потока: за ним ведь приходится тянуть все кеши.Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его квант истёк, его вытеснил поток B. Вдруг ядро 2 начало простаивать, а A стоит в очереди на ядро 0, которое находится в той же ноде, что и ядро 2. Ядро 2 должно простаивать? Или может всё таки лучше забрать поток A себе? Планировщик скорее всего сделает последнее (за вычетом ограничений affinity и подобного). Кэши просто так никто перетягивать не будет. Поток B вероятнее всего уже весь кэш L1 заполнил своими данными. А L2 может вообще быть общим для ядер 0 и 2. Что перетягивать? Как перетягивать? Да, будут cache miss'ы. Но это лишь замедление работы, а не полное простаивание ядра (пока есть работа в очереди).
> Какая разница планировщику какие ядра будут простаивать без работы?
Они не будут (простаивать без работы). См. выше.
> Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное?
Не зачем. Но поток не может вечно крутится на ядре. Он может крутится лишь определённый кусок времени (квант), затем он должен уступить другим потокам. В этот момент и может произойти ситуация, описанная выше, где поток A - это как раз "поток кушающий 100% времени процессорного ядра".
> Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе?
Нет, конечно. Потоки могут выполняться не только на последнем использованном для выполнения ядре, они действительно могут "перекидываться". См. пример выше.
> На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на твоё первое сообщение 4.81.
> Я отмечу, что ты не предлагаешь никакой альтернативы им.
В моём же сообщении 3.61 я сразу написал:
> Советую почитать Windows Internals, например 7-ое издание.Ибо там, даже если очень лень вникать, просто из содержания можно извлечь ложность утверждений из статьи.
> Thread selection on multiprocessor systems
> Heterogeneous scheduling (big.LITTLE)Про то, что планировщик Windows знает, про разницу между физическими и логическими ядрами, рассказывает раздел "Package sets and SMT sets", но увы, тут уже придётся вчитаться хотя бы в первый его параграф.
> Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
Я не знаток конечно, я лишь консультирую по NT Internals. Зачем я должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? Смысл пересказывать содержимое книги?
>> В перекидывании потока: за ним ведь приходится тянуть все кеши.
> Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его
> квант истёк, его вытеснил поток B.С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают?
>> Какая разница планировщику какие ядра будут простаивать без работы?
> Они не будут (простаивать без работы). См. выше.Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем? Там в любой момент времени, потребляется 100-101% времени одного ядра, потому что есть один поток жрущий 100% одного ядра, и фоновые процессы, которые практически всё время спят.
>> На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
> Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на
> твоё первое сообщение 4.81.В моём первом сообщении был вопрос: "твои придирки, как я понял, относятся не к фактической части, а к теоретической?". Фактическая часть -- это как раз те самые графики, которые демонстрируют как имея несколько свободных ядер, венда перекидывает поток жрущий 100% времени одного ядра между ядрами. Теоретическая часть -- это объяснение происходящего с отсылками к устройству планировщика задач венды.
>> Я отмечу, что ты не предлагаешь никакой альтернативы им.
> В моём же сообщении 3.61 я сразу написал:
>> Советую почитать Windows Internals, например 7-ое издание.Иди ты с этой альтернативой знаешь куда? Мне венда не въелась совершенно, из любопытства я могу почитать обсуждаемую статью, чтобы узнать немного о том, как она работает. Но всякие вендовс интерналс я прекратил читать лет двадцать назад, когда заглянул в linux и увидел, что здесь можно читать не дурацкую писанину технических писателей, а непосредственно исходный код.
>> Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
> Я не знаток конечно, я лишь консультирую по NT Internals.Лол. Мне нравятся твои консультации: "идите и почитайте windows internals". Тебе за такие советы реально кто-то платит денег? Вообще, насколько я понимаю задачу консультирования, в ней очень важно иметь навык понимания собеседника, потому как ежели консультант не в состоянии понять того, кого он консультирует, то он действительно никогда не сможет дать совета лучше, чем "RTFM". Второй важный навык -- это умение объяснять и отвечать на вопросы. Ты здесь и сейчас продемонстрировал, что ни один из этих навыков тебе недоступен. Я чёрть-его-знает-сколько времени выуживал из тебя ответы на простые вопросы, получая ненужные мне ответы на вопросы, которых я не задавал. Как ты вообще работаешь консультантом при этом?
В качество профориентационного совета: тебе лучше податься в маркетинг или в политику -- там как раз очень полезно умение уходить от прямых вопросов, создавая при этом впечатление открытости и готовности развёрнуто отвечать на любые вопросы.
> Зачем я
> должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек,
> если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков?
> Смысл пересказывать содержимое книги?Мне не нужно содержимое книги, мне хочется знать короткое объяснение простому феномену: почему венда жонглирует потоком между свободными ядрами, хотя оно могло бы оставить его крутится на одном ядре.
> С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают?"С какого полового члена" взято что они простаивают? Из сценария из статьи, точнее из графика из неё, из которого не понятно даже это нагрузка от одного процесса или от всей системы? Я про свой сценарий, который может совпадать со сценарием из статьи, когда помимо одного однопоточного приложения есть неравномерная нагрузка и на остальные ядра (от других процессов), но не 100%.
> Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем?
Конечно читал, ибо реагирую.
> В моём первом сообщении был вопрос: "твои придирки, как я понял, относятся не к фактической части, а к теоретической?". Фактическая часть -- это как раз те самые графики, которые демонстрируют как имея несколько свободных ядер, венда перекидывает поток жрущий 100% времени одного ядра между ядрами. Теоретическая часть -- это объяснение происходящего с отсылками к устройству планировщика задач венды.
Если так поставить, да. Мои "придирки", "относятся не к фактической части, а к теоретической".
Ну и спасибо за полезные советы, я ими непременно воспользуюсь по назначению.
>> С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают?
> "С какого полового члена" взято что они простаивают? Из сценария из статьи,
> точнее из графика из неё, из которого не понятно даже это
> нагрузка от одного процесса или от всей системы?Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра.
> Я про свой
> сценарий, который может совпадать со сценарием из статьи,Да кому он нужен твой сценарий, если в статье идёт обсуждение вполне конкретного сценария? И вообще, если ты меняешь сценарий, ты хоть предупреждай собеседников. Я бы даже не парился общаться с тобой, если бы с самого начала знал, что ты на своей волне сам с собой разговариваешь.
>> Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем?
> Конечно читал, ибо реагирую.https://www.physics-astronomy.org/2019/04/marijuana-contains...
> Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра.В этой статье нет даже объяснения, что этот график изображает. "Single-threaded workload bouncing between cores". Это график той самой нагрузки (только от неё)? Или нагрузки на ядра (в целом, с учётом остальных потоков других процессов)? В статье нет даже упоминания этого графика, хотя контекстуально он вероятно релевантен. Но он просто "есть", в отрыве от статьи.
Я привожу пример сценария, в котором график будет корректным, соответствовать контексту, но означать не "тупость" планировщика, как это указано в статье. Да и помимо этого графика в статье есть ошибочные утверждения (что легко проверяется с помощью качественной книги или IDA Pro/Ghidra/...).> [14.335] Да кому он нужен твой сценарий, если в статье идёт обсуждение вполне конкретного сценария?
> [13.330] сценарий, который может совпадать со сценарием из статьи:/
> [14.335] И вообще, если ты меняешь сценарий, ты хоть предупреждай собеседников.
> [11.318] Представим ситуацию.:/
Спасибо за ссылку, могу вкинуть ещё парочку интересных.
>> Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра.
> В этой статье нет даже объяснения, что этот график изображает. "Single-threaded workload
> bouncing between cores". Это график той самой нагрузки (только от неё)?
> Или нагрузки на ядра (в целом, с учётом остальных потоков других
> процессов)? В статье нет даже упоминания этого графика, хотя контекстуально он
> вероятно релевантен. Но он просто "есть", в отрыве от статьи.У меня не возникло проблем понять этот график. Автор сделал открыл какую-то тулзу, которая рисует график загрузки ядер, прибил все процессы, которые давали заметную нагрузку, после чего запустил какую-то однопоточную нагрузку -- может быть это был while(1) i++; скомпилированный с -O0, может быть это было какое-то приложение, которое считало гуглоплексы знаков пи, может это было что-то ещё. И он получил графики, которые мы видим.
Я не вижу способа, как он здесь мог накосячить -- запустить что-то, что блокировалось на вводе-выводе? Но график был бы иной, он бы не достиг 100% загрузки процессора. Может у него был какой-то другой процесс, который съедал, допустим, 20% времени процессора, а его процесс кушал 80%? Или его нагрузка была многопоточной? Но в этом случае ему сильно повезло, что эти процессы так чётко отъедали процессорное время так, чтобы в сумме получалось бы 100%, и ещё ему повезло, что они всегда по двум ядрам раскидывались и не занимали остальные. Короче, я не вижу, как он мог сделать что-то не то.
Может я неправильно понимаю график, и эти кривые отражают что-то иное, не загрузку хардварных тредов? Но что, например? Я не вижу, что это может быть ещё.
Я выше дважды сказал "я не вижу", если насчёт хотя бы одного "я не вижу", ты можешь сказать "а я вижу" и объяснишь, что именно ты видишь, то я соглашусь с тобой, что тут серьёзный косяк со стороны автора. Если ты не можешь предположить ничего, значит косяка тут нет: автора и его картинку можно понять единственным образом и дополнительных пояснений не требуется.
> Я привожу пример сценария, в котором график будет корректным, соответствовать контексту,
> но означать не "тупость" планировщика, как это указано в статье.Ты не приводишь сценария, который бы соответствовал графику. Если бы на систему была сколь-нибудь существенная нагрузка кроме тех вычислений знаков пи, то мы бы это видели. Более того, на графике мы видим пару всплесков фоновой активности, когда вдруг другие ядра ненадолго просыпаются и начинают что-то делать.
> Спасибо за ссылку, могу вкинуть ещё парочку интересных.
Вообще эта ссылка была ответом на утверждение, что из того, что ты реагируешь, всенепременно вытекает, что ты читал статью. Не вытекает. Эти реакция и чтение не обязательно сопутствуют друг другу.
Я уже начинаю уставать от этого диалога, если честно.Я не говорю, что автор графика накосячил (вероятнее всего ошибок в графике нет, хотя к нему не хватает комментариев). Я утверждаю, что подобное поведение (перескакивание потока с ядра на ядро) легко объясняется без пинков в сторону "примитивности" планировщика. Я предоставляю очень вероятный сценарий (в сообщении 11.318), в котором график абсолютно корректен.
Дополню сценарий дополнительными комментариями:
Планировщик, запускаемый на только что освободившемся ядре 2 (которое могло выполнять очень лёгкую работу, и/или в конце добровольно отдавать управление, поэтому на графике, даже если это график полной нагрузки каждого ядра, оно могло быть любым кол-вом процентов), решает забрать нашу сложную ("single-threaded workload", поток A из 11.318) работу у ядра 0, которая недавно была вытеснена другим потоком по причине истечения кванта времени (SMT, preemptive scheduling). Это позволяет избежать простаивания на любом ядре в любой момент времени (что, конечно, хорошо), но да, это действительно перекидывание потока с ядра на ядро. Да, оно ведёт к L1 cache miss, но есть хороший шанс (обеспеченный алгоритмически, ибо планировщик Windows знает про сеты процессоров и NUMA ноды), что L2 или L3 всё ещё содержат нужные данные.
Подчеркну, что ядро 0, отдав наш поток A, могло начать заниматься чем угодно (любая ненулевая нагрузка любой сложности), но это должно было бы произойти (если есть хотя бы один ещё поток в очереди), ядро должно хотя бы иногда переключать контекст (опять, кванты времени). А ядро 2 могло в любой момент (разумеется, после того, как ядро 0 переключилась с потока А) украсть поток A, чтобы не простаивать. Объективно, это позволяет эффективнее использовать все ядра.В статье же, по незнанию автора (статьи, ибо автор статьи и графика может не совпадать) этот эффект истолковывается иначе (и делаются неверные выводы), якобы ядро 2 крадёт поток A у ядра 0 только потому, что оно освободилось (в реальности ядро 0 просто отключилось от потока A по расписанию, и начало другую работу; если другой работы бы не было, планировщик продлил бы т.н. Quantum Target и вернул управление потоку A). Утверждая про некорректное истолкование, я напрямую опираюсь на чётко описанный материал в самой авторитетной технической книге по внутренностям Windows.
> Объективно, это позволяет эффективнее использовать все ядра.Да, тогда когда занятых работой потоков больше чем ядер. Когда их меньше, получается фигня.
> В статье же, по незнанию автора (статьи, ибо автор статьи и графика
> может не совпадать) этот эффект истолковывается иначе (и делаются неверные выводы),
> якобы ядро 2 крадёт поток A у ядра 0 только потому,
> что оно освободилось (в реальности ядро 0 просто отключилось от потока
> A по расписанию, и начало другую работу; если другой работы бы
> не было, планировщик продлил бы т.н. Quantum Target и вернул управление
> потоку A). Утверждая про некорректное истолкование, я напрямую опираюсь на чётко
> описанный материал в самой авторитетной технической книге по внутренностям Windows.Ах вот оно что... Знаешь как планировщику следовало бы поступить? Ему бы следовало мониторить активность задач, и заметить, что одна задача серьёзно занята чем-то и хочет сожрать столько процессорных квантов, сколько возможно, и в то же время он должен был заметить, что суммарная производительность остальных ядер более чем в 100 раз больше, чем требуется остальным задачам, а раз так, то следует прибить гвоздями занятую задачу к тому ядру, на котором он выполняется, и шедулить остальные задачи по свободным ядрам.
Именно это делает ядро linux, именно поэтому в аналогичной ситуации на линуксе, сильно занятая задача будет "захватывать" ядро на несколько секунд за раз, а не на 40 миллисекунд в среднем. Ядро windows этого не делает, что ты своими объяснениями подтверждаешь. Именно поэтому "dumb windows scheduler", и "ненужное перекидывание потоков".
Обрати внимание, несмотря на техническую неграмотность, автор статьи лучше тебя ухватил суть проблемы. Это очень похоже на тот редкий случай, когда избыточная грамотность вредит.
Самое интересное, что твоё более точное описание ничего не изменило в моём понимании ситуации. Ну, то есть, понятно, что крайне сложно выстроить идеальную ситуацию, когда в системе есть ровно один процесс, и всегда есть много процессов, и даже если они и спят 99.99% времени, всё же они иногда просыпаются и требуют квантов процессорного времени. Это настолько понятно, что не заслуживает даже упоминания, если по-хорошему. И способность венды держать занятый поток на одном ядре в идеальной ситуации, когда нет этих почти-всегда-спящих процессов -- совершенно бесполезная способность, потому что так не бывает. А как при этом объяснять это -- "ядро крадёт задачу" или "планировщик выделяет квант другой задаче" -- с мой точки зрения не важно совершенно: это просто разные уровни объяснений. Так же как одну и ту же программу можно написать на lisp'е или на asm'е, в каждом случае выбирая различные абстракции в предметной области, так и объяснять можно на разных уровнях и в разных абстракциях.
> Да, тогда когда занятых работой потоков больше чем ядер.Это практически всегда так. На моём домашнем десктопе с 6 логическими ядрами, даже с незапущенным IIS и SQL Server, порядка 240 процессов и 4300 потоков. 0% ни на одно ядро я никогда не наблюдаю.
> Ему бы следовало мониторить активность задач, и заметить, что одна задача серьёзно занята чем-то и хочет сожрать столько процессорных квантов, сколько возможно,
Угу, он это и делает.
В Windows Server базовый квант времени (Quantum Reset) в 4 раза дольше, чем в Windows, специально чтобы снизить количество переключений контекста, но и в клиентских редакциях можно включить такой квант. В клиентских редакциях настоящий квант времени зависит от типа процесса: foreground/background, что тоже может продлевать квант времени. Также есть механизм Priority Boost, но он зависит от конкретной "single-threaded workload".
Когда заканчивается квант времени, почти всегда будет использован механизм, который позволяет просто продлить квант времени. Можно повысить приоритет (понизить niceness в Linux), тогда переключение потока на ядре будет ещё реже.> суммарная производительность остальных ядер более чем в 100 раз больше, чем требуется остальным задачам
Очень опасное наблюдение, которое целиком опирается на неизменность нагрузки потоков (что, вообще говоря, очень большая редкость). Планировщик Windows записывает историю нагрузки, и использует её, но не на горячем пути планировщика, а в более редких/сложных ситуациях (см. далее).
> шедулить остальные задачи по свободным ядрам
Так и происходит, это свободные ядра сами делают (планировщик, запускаемый в их контексте).
Перекидывание может произойти в редком случае: все остальные потоки приоритета потока A и выше не готовы к выполнению. Чем "дальше" два ядра, тем меньше вероятность перекидывания (т.к. планировщик знает про конфигурацию ядер и итеративно расширяет поиск готовых к исполнению потоков, но до определённого порога, обычно границей является NUMA нода). Как видно из того же графика (опять, на нём нет даже масштаба времени), перекидывание практически всегда происходит между двумя (редко - тремя) ядрами (а в Zen 2 каждый CCX содержит 4 ядра!).---
Почитал я про стандартный CFS (опирался на Wikipedia, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-de.../ и на https://opensource.com/article/19/2/fair-scheduling-linux). Ни в коей мере не утверждаю правильность понимания, но следующий набор замечаний.
> The CFS scheduler has a target latency, which is the minimum amount of time—idealized to an infinitely small duration—required for every runnable task to get at least one turn on the processor.
> Of course, an idealized infinitely small duration must be approximated in the real world, and the default approximation is 20ms. Each runnable task then gets a 1/N slice of the target latency, where N is the number of tasks.Немного (сильно) противоречит утверждению:
> сильно занятая задача будет "захватывать" ядро на несколько секунд за раз, а не на 40 миллисекунд в среднем.
Или это про то, что CFS будет всегда возвращать управление "сильно занятой задаче"? Но всё равно, что с остальными потоками в очереди? Никогда не получат ядро?
Далее вводится очень разумный концепт minimum granularity, затем знакомый термин virtual runtime (vruntime) (в Windows эта метрика более чёткая, в плане, на пару счётчиков больше).
> Suppose task T1 has run for its weighted 1/N slice, and runnable task T2 currently has the lowest virtual runtime (vruntime) among the tasks contending for the processor. The vruntime records, in nanoseconds, how long a task has run on the processor. In this case, T1 would be preempted in favor of T2.
> The scheduler tracks the vruntime for all tasks, runnable and blocked. The lower a task's vruntime, the more deserving the task is for time on the processor. CFS accordingly moves low-vruntime tasks towards the front of the scheduling line. Details are forthcoming because the line is implemented as a tree, not a list.Но ведь это означает, что та самая "single-threaded workload" будет иметь очень большой vruntime и всегда оказываться далеко в "очереди" (которая на самом деле дерево) на исполнение, т.е. она всегда будет уступать более лёгким/быстрым (термин мой) потокам. Не проблема, но интересное замечание.
> Yet configurable scheduling domains can be used to group processors for load balancing or even segregation. If several processors share the same scheduling policy, then load balancing among them is an option; if a particular processor has a scheduling policy different from the others, then this processor would be segregated from the others with respect to scheduling.
В планировщике Windows это называется processor package, так что это знакомо.
Затем я открываю статью "The Linux Scheduler: a Decade of Wasted Cores", патчи из которой, как я слышал, были приняты в планировщик несколько лет назад. Интересный материал, затем я дохожу до этого момента:> Now we have a new problem of balancing work across multiple runqueues.
> Suppose that one queue has one low-priority thread and another has ten high-priority threads.
> We could have each core check not only its runqueue but also the queues of other cores, but this would defeat the purpose of per-core runqueues.Вот, серьёзное алгоритмическое отличие от планировщика Windows. Планировщик Windows полезет в очереди других ядер в порядке удалённости от текущего. В то время как CFS:
> Therefore, what Linux and most other schedulers do is periodically run a load-balancing algorithm that will keep the queues roughly balanced.
> Since load balancing is expensive the scheduler tries not to do it more often than is absolutely necessary. In addition to periodic load-balancing therefore, the scheduler can also trigger emergency load balancing when a core becomes idle.Как я понимаю, Windows предпочитает балансировать нагрузку "здесь и сейчас", когда ядро готово войти в состояние простоя, а CFS выделяет это в отдельную регулярно запускающуюся рутину (с возможностью экстренного запуска как в Windows). Сравнивать лучше/хуже не буду, но отмечу, что подход CFS более предсказуем, в то время как планировщик Windows почти* всегда работает в контексте "надо прямо сейчас решить что дальше делать".
почти* - есть например отдельный алгоритм по борьбе с CPU Starvation и priority inversion, который работает вне контекста конкретного потока, но он асинхронный и работает как "консультант", рекомендуя правки к финальному решению планировщика Windows, опираясь на историю нагрузки каждого потока.
Сделаю вывод из прочитанного: Linux предпочитает простаивание ядер (если даже load balancing и перекинет все потоки кроме потока A на другие ядра), но удерживает (если load balancing так решит) потоки в пределах одной runqueue. Windows действует "жадно", решая, что лучше в каждый момент (но опираясь на историю в *некоторых* случаях), что может приводить к краже потоков, если эта кража дешёвая (внутри одного processor package, ибо более широкие поиски задействуются очень редко), а другой работы соответствующего приоритета нет. Это иногда случающееся перекидывание потоков имеет обоснование (снижение количества простаивающих ядер), но cache miss'ы могут случаться чаще (они весьма вероятны и на CFS, ибо если load balancing оставит хотя бы один другой поток на ядре, где выполняется поток A - точно так же будет борьба за L1 и L2 в течение каждого target granularity, а отношение ядер/потоков явно не в пользу ядер).
> Забавно читать про "более простые планировщики". Знания внутренностей ядра Windows типичного
> Linux-апологета видимо ограничивается уровнем Windows XP/слитых исходников Win2000.А что, в тех сорцах есть планировщик?))
Без понятия. Если не там, то вероятно в Windows Research Kernel есть. Там и исходники посвежее должны быть (Windows XP, а не 2000).
Марк, это ты? =)
технически у виндовс нет универсального планировщика который создан с учётом и серверов и десктопов.. они сознательно от этого отказались разделив версии системы.. и да планировщик винды заточенный под десктопы сейчас возможно даже сложнее чем любой другой..
Технически, у Windows только универсальный и есть. Код Windows клиентских и серверных редакций (отвечающий за планировщик потоков) един. Есть различия в стандартных значениях констант (Quantum Reset например, у серверных редакций промежуток времени выполнения одного потока дольше в 4 раза). Есть ограничения по количеству ядер (опять, зависит от редакции, на бывшей Home редакции не получится поднять датацентр, да и Pro ограничения маловаты для этого). Но планировщик один. В некоторых случаях он лучше Linux'ового (например для домашнего ПК, или для небольших датацентров из коробки, т.е. до того как прийдёт профи Linux админ и начнёт крутить параметры sysctl).
Можно что угодно говорить про преимуществах ядра винды, но если нельзя убедиться в этих достоинствах, недостатках и особенностях своими глазами — грош им цена. Не раз и не два я в своей жизни нырял в исходники как линукса, так и дарвина, чтобы расковырять баг или разобраться в поведении. А когда такие баги попадались под виндой, я глядел в глубокие стектрейсы из ядра да системных dll, разводил руками и вставлял костыль.
Любой код можно расковырять, нужно лишь быть достаточно любопытным (и имеющим время до deadline, если таковой имеется). И вероятнее всего окажется, что ошибка в своём коде, а не в ОС, причём в неправильном использовании API (ведь кто читает документацию?), как очень часто рассказывает Raymond Chen в блоге The Old New Thing. Но никто не спорит, если есть исходники - не надо запускать IDA/Ghidra/Cutter/radare2/WinDbg.
Я понятия не имею, что там в windows (не интересует вопрос), но крутить в юзерспейсе спинлоки с yield-ами на SMP - это выстрел себе в ногу, это в чистом виде UB. Такой подход уместен разве что в ОС с кооперативной многозадачностью, типа Windows 3.1.
Там дело еще осложняется тем, что код исполняется в виртуалке.
Ха, ну это вообще тогда чувак измерял громкость жужжания комара, стоя рядом с работающим самолетным двигателем.
> В каждой версии Windows планировщик значительно усложнялсяИ все меньше винды оставалось на top500. Это факт, а факт - самая упрямая вещь на свете.
>Windows же нацелен на работу на домашних ПК либо на серверах до 1000 (1280 если быть точнее) ядер
Винда - игровая платформа. Только.
>где должны хорошо работать приложения, написанные любым программистом, на любом хипстерском ЯП (Go, JS, ...) и не очень (C, C++, ...).
Игры, например. Замечательно работают. В одно ядро.
У нас каждый первый комментатор опеннета похоже на топ500 работает.
Статистику в студию...
На что статистику? Как мой саркастический комментарий по поводу 500 компьютеров из множества всех относится к теме? Да собственно так же как твой комм про топ500. Давай не про топ500 тогда вбросим а про космос. Там твои что х86 что линухи в пролете.
> Винда - игровая платформа. Только.Поражают воображение легенды и мифы опоздавших родиться мамкиных погромиздов.
> И все меньше винды оставалось на top500. Это факт, а факт - самая упрямая вещь на свете.Благодаря таким комментариям начинаешь забывать, что у Linux есть другие, более классные достижения.
> Винда - игровая платформа. Только.
О божечки. Как же некоторые ограниченны. Даже в магазины наверное не ходят, не видят Win2000/WinXP на каждом кассовом терминале (хотя может в default city уже все на Linux, я просто в России живу). Ну и работают наверное фрилансом, ибо в офисах (даже в IT-компаниях) Linux как-то не часто можно увидеть.
> Игры, например. Замечательно работают. В одно ядро.
Зацикленность на одном. Игры - похоже лимит воображения.
Мышление из 2005 (когда там СТАЛКЕР: Тень Чернобыля вышла?). Все игровые движки многопоточные, как на Windows, так и на Linux. Советую почитать исходники Unreal Engine или CryEngine, если хотите мейнстримных движков. Я уже не говорю о "просто померить".
Js другое хипстерское убожество на Винде настолько тормознуточто линукс встроили - wsl
а потом wsl2 на виртуалки переделали
Справедливости ради, node.js на Windows тормозит не из-за сетевого стэка либо планировщика, а из-за файловой подсистемы (включая, но не ограничиваясь, NTFS). А любая вещь на JS не может работать без папки node_modules с миллионом файлов внутри. Увы.А файловый стэк - да, известная боль на Windows.
WSL - замечательное начинание, которое мне позволяет из Windows работать с Valgrind'ом без виртуалок, дебажить порты Win32 приложений под Linux, не париться по поводу копирования в буффер обмена (cat | clip.exe, вместо cat | xclip, что не работает, ибо какого лешего я должен помнить про необходимость -selection с параметром, который тоже надо помнить? Почему Linux для меня, десктопного юзера, так не дружелюбен?).
WSL2 - увы, шаг назад с моей точки зрения.
Линус прав в том что спинлоки надо уметь. Скорее всего автор теста не читал
https://stackoverflow.com/questions/4725676/how-does-x86-pau...
и
https://stackoverflow.com/questions/12894078/what-is-the-pur...а зря!
Статью не читай @ сразу отвечай?Всё там правильно сделано. Опозорился тут как раз Линус, публично признав что его ОС не подходит для десктопа и что сделано хреново ради "универсальности".
Да это прямо в документации написано http://man7.org/linux/man-pages/man3/pthread_spin_init.3.html в NOTE.Линус просто man процитировал.
Для игр вообще должны применяться системы без многозадачности. Или с вытесняющей многозадачность там и задержки будут меньше. А все эти гугл стадии на веселеньком универсальном железе это прямой путь к лагам. Только для казуальщины может быть подойдут.
Линус же указал страждущему правильный путь :)
Есть же планировщик реального времени FIFO. В нем вытеснения нет. Каждый spin-lock гарантировано дождется освобождения без прерывания.
Если spin-lock с таким же номером ядра/процессора как и твой, можно смело делать sched_yield, все равно другой тред занял этот лок на твоем же ядре. (И cpu affinity не забыть) :)
я в целом изначально удивлён что на стадии не риалтайм использовали, но думаю инженеры гугла по разному поиграются и в итоге найдут специфичное для своей системы решение которое будет лучше.
Да пусть сначала гуглоиндусы все свои сервисы и приложения нормально сделают, а потом что-то вякают на другие системы. Не говорю, что в линуксе все просто супер на десктопе... НО гуглоидусы бы лучше помалкивали. #imho
Думаю Стадию закроют в 2021-2022 году. :-)
>> Линус возразил, что планировщик Linux является универсальным, оттачивался десятилетиями и оптимизирован не только для рабочего стола и игр, но и для других видов нагрузки, например, для серверных систем, поэтому учитывает множество нюансов при планировании выполнения задач.Занятно, Линус обвиняет другого разработчика в некомпетентности, при этом сам подтверждая его слова, что планировщик линукса говно?
Разраб написал, что планировщик крайне плох для десктопов, а их величество оправдывает это "универсальностью". Не уж то Линус так против продвижения линукса на другие системы? Почему нельзя сделать 2 разных планировщика, которые будут работать лучше в определённых ситуациях, и дать возможность выбора пользователю одного из них? Или "опенсорс - пишите сами для себя"? По его мнению что, строители и ювелиры работают стандартизованными молотками? "Понапридумывали кувалд -они ни кому не нужны"?
Предположу что делать кастомную систему под каждую задачу ДОРАГА. Есть же системы реального времени для своих задач и прочие узкоспециализированные ос и стоят они дорага!!!!
Ну, стоит заметить, что север и десктоп очень разные и широко распространённые задачи. Совсем неплохо было бы иметь 2 планировщика. Та же jvm имеет 2 jit компилятора для сервера и клиента, бо юз кейсы очень разные и потенциальный выйгрыш того чтобы заморочится.
Погоди-ка под десктоп линукс вроде особо и не заточен судя по перекосу в распространении. Или Суперкомпьютеры так и ждут чтобы потормозить?
Не десктоп а клиент. И да, на линуксе десятки миллионов если не больше клиентов , в т.ч. десктопы, планшеты, смартфоны, телевизоры, в общем всё что имеет GUI.
>в т.ч.в таком случае это уже десятки миллиардов, не?
> jvm имеет 2 jit компилятора для сервера и клиентаРазве? AFAIK, компилятор один, отличаются только дефолтные настройки типа продолжительности сбора статистики перед компиляцией и вероятности перехода от интерпретатора сразу к C2.
> при этом сам подтверждая его слова, что планировщик линукса говно?ага ты его раскусил
удали линукс и пользуйся windows 10,
только не забуть проапгрейдится на мощный компо чтоб windows было не говном и не лагало
Если тебе что-то не подходит то это не значит что оно гавно.
>> Так как измерение производительности выполняется на основании абсолютных значений таймера, определённые в тестах задержки охватывают не только задержки в обработчике блокировки, но и код, который был выполнен в другом контексте, т.е. измеряют не только то, что пытался измерить автор теста, но и "шум" от других вычислений в системе.Это финиш. Как не странно, в конечном счёте важно общее время выполнения - отзывчивость системы. И толку 0 от того, что "чистое время всего 1 мкс", если итоговая задержка 1 с. Потому что ответ пришёл через 1 с, а не 1 мкс. Именно это общее время и есть самый главный показатель, и в нём отражены все накладные расходы в системе. В том числе и то, что в момент обработки планировщик вытеснил наш поток и отдал управление другим задачам.
Вместо того, чтобы версии выпускать, лучше бы развитием системы занялся. Универсальная система, которая одинаково фигово работает как на десктопе, так и на серверах, такое себе решение. Вместо тешения своего чсв, лучше бы добавил возможность оптимизации под задачи пользователей. Та же винда с незапамятных времён имеет возможность оптимизации, банальным переключением флажка в формочке, без перекомпиляций. А эти даже с исходниками не могут до сих пор реализовать.
Наберите в поисковике "система реального времени", ознакомьтесь с определением -- есть куда двигаться дальше. ;)
Можно и линукс с реалтайм ядром запускать, но есть минусы- Приложения реального времени выполняются в пространстве ядра, следовательно, они могут переписать часть памяти ядра и сломать систему
- Взаимодействие между RT-подсистемой и Linux не может быть реального времени
- Ядро Linux выполняется в бэкграунде, следовательно, задачи Linux могут испытывать большие задержки
- Невозможно использовать драйверы Linux в задачах реального времени, следовательно, разработчики приложений реального времени вынуждены переписывать драйверы устройств поверх RT-подсистемыРезультат конечно может и быстрый, но минусы какбэ намекают.
Правомерны ли исходные претензии к не реалтайм системе?
Это если нужен hard-realtime. Для soft-realtime хватит и обычного preempt_rt.
Я не знаю как на x86, на cortex-a нас задержки устраивают. С sched_fifo в нашем проекте я пока не видел провалов планировщика, когда задача получила управление позже, чем ожидается.
Soft-realtime — это маркетинговое изобретение микрософта.
Либо система гарантирует задержки, либо нет. Величины этих гарантированных задержек - дело десятое.
Разница есть. Системы hard realtime ничего и никогда не должны пропускать. Потому что пропуск события в них это полный сбой. Самый набивший оскомину пример это кардиостимулятор. Если он не вовремя выдаст импульс или вовсе пропустит это может привести к остановке сердца.
>Самый набивший оскомину пример это кардиостимулятор.ОС общего назначения никогда не применяют в критических системах, связанных с жизнью человека. Вопрос закрыт.
О том и речь. Hard-realtime это специально спроектированные системы, способные эти требования выдерживать. Linux это soft-realtime.
>Это финиш. Как не странно, в конечном счёте важноЛучше бы ты в lklm патчи присылал.
Ты же обладаешь сакральным знанием:
>Та же винда с незапамятных времён имеет возможность оптимизации, банальным переключением флажка в формочке
>Именно это общее время и есть самый главный показатель,Если оно правильно измерено. А если в одном случае в измеренное время паузу от вытеснения задачи, а в другом случае не считали, то это и было тем, что измерили в ходе эксперимента.
Линус - в своём репертуаре.
Начиная со своего знаменитого спора с Таненбаумом.
А ведь профессор оказался прав, как бы зомбикам(и) не внушалось обратное.
В мире надёжности лучше - микро/экзо ядра, аппаратно разделённые адресные пространства процессов, и механизм сообщений над блкориующими каналами. Всё другое - костыли над костылями для скорбных умищем и танцы с бубном.
И над этим всем великолепием зависла IRS таймера, переключающая контексты? ;)
Тот-то Столлман так Гурд и не дописал. А все потому что это ваше микроядро тупо сложно писать. А время программиста дороже машинного времени.
Линукс крутится - грубо, на 10 млн серверов. Это 20 млн процессоров, это $1000 каждый, это 20 млрд.долл. Время программистов дороже этой суммы? Rly?
Лол один программист стоит 100 000$ в год. Для примера за 60000$ можно купить вот такой https://www.amazon.com/Supermicro-F618R2-RT-Bay-Motherboard-...конфиг на 16 физических процессоров и это за раз, а не за год и стоять такой в стойке будет уж никак не меньше 5 лет условно 12000 долларов в год. Представь что половина из них нужна только чтобы компенсировать неидеальность кода. А чтобы поправить условную проблему с планировщиком и запилить под конкретную задачу нужен минимум отдел с лидом всякими менеджерами, чтобы программистам было тупа не скучно. Это не меньше 8 человек. Итого для решения проблемы с планировщиком надо 800 000$ в год. И решение со всеми сопровождениями и делами рассчитаем года на 3 пока не выпустим обновленную версию. Итого 2 400 000$ На что суровый бизнес какбэ скажет 2_400_000/30_000 это 1280 ядер. Просто купим побольше ядер и все будет пучком.Процедура подсчета чужих денег закончена.
https://www.amazon.com/Supermicro-F618R2-RT-Bay-Motherboard-...
Глупость какая-то. Куча металлолома. 2 х 14 Тб HDD Toshiba в зеркале раз в 10 дешевле.
Если на разработку планировщика о 3 тыс строк (столько весит ULE) требуется отдел на 8 человек и три года разработки, то становится понятным, почему линуксячий код - такое фуфло, типовое обновление - прикручивание свистелок, а линукс называют конторой для отмывания бабла.
Этим и отличается суровый энтерпрайз от поделок Васяна. Васян может и напишет 3000 строк и они вполне вероятно заработают только когда это все навернется он будет не причем. А вот отдел это уже весомая величина там и виноватых можно найти и работать заставить. И сделать так чтобы было с перламутровыми пуговицами тоже к ним. И по хорошему если что-то годное выйдет они и в апстрим зальют.Но зачем когда ты можешь заплатить те же деньги шапке ака межбизмашу и все не критически острые углы ты можешь обходить покупая больше железяк. А уж что там в шапке напишут Линус уже написал что они там напишут.
Уже написанный launchd когда внедрите? Или трех подходов оказалось недостаточно (что, впрочем, не помешало пытавшимся защитить на этой теме дипломы)?
>> разработку планировщика о 3 тыс строк (столько весит ULE)
> Уже написанный launchd когда внедрите?Начался юлеж.
И да, опеннетчики, по причине ношения маечки с пингвинчиком и установленной в дуалбуте с виндой бубунточки отождествляющие себя с разработчиками - забавны.
При том, что эти сервера крутят в солидном % случаев скриптоту, претензия к неоптимизированности чего-то там в ядре просто смешна. Тем более что за линукс они и 1$ не платят.
Это именно то, чего вы хотели, чего теперь плакаться. А с другой стороны - что, у амазона или ойбиэм не нашлось бы лишних пары килобаксов, чтобы запилить я публичное ядро нормальный планировщик? Конечно же, нашлось бы. Просто им это - не надо. Они у себя втихую будут крутить закрытую инфраструктуру на нормальном планировщике, а остальные облизнутся. И так в линуксе со всем - что с планировщиком процессов, что с планировщиком вввода-вывода, что с сетевой подсистемой, что с файрволлингом - всё работает, но недоделанное, а доделать - не дают.
> И так в линуксе со всем - что с планировщиком процессов,
> что с планировщиком вввода-вывода, что с сетевой подсистемой, что с файрволлингом
> - всё работает, но недоделанное, а доделать - не дают.Но забавляет вера неофитов, что лютая махровая проприетарщина, каковой ещё с конца девяностых является ведро пингвинукса — плод добровольного благотворительного вклада миллионов^W тысяч бескорыстных программистов в общее дело ради процветания всего человечества. Ибо свобода превыше всего!
Если ты наивен, не думай, что все такие-же:
И да, по исходникам таки работает GPL. Есличо.
Работают, работают. Только толку от GPL, если в апстрим никто ничего впилить не может без одобрения корпораций, которыми же решаются вопросы архитектуры. И на выходе мы получаем такую же винду, только с открытыми сырцами, а больше разницы никакой нет, потому что никакое комьюнити уже давно ничего не решает.
Кто виноват и что делать - вечный вопрос :)
А толку от GPL - закрыть можно не всё.
А с "та же винда" - это ты загнул. Фиг ты в винде планировцик поменяешь :)
И в линуксе - тоже фиг поменяешь.
> И да, по исходникам таки работает GPL. Есличо.Только вот в современных облачных реалиях все что не AGPL - подарок корпоративным дядям из CloudFlare, Amazon, Google, Oracle и прочих.
Впрочем, Tesla обещающая 6 лет как "совсем уже почти скоро откроем код!!" или китайцы, откровенно кладущие болт на все эти "заморочки бледнолицых демонов" - тоже неплохо демонстрируют, как это работает на самом деле.
Зато гугл взял и написал. И дрова будут. Одно дело какие-то nicheброды без денег и с GPL с хитрым простым как 3 копейки планом поиметь корпорации, а другое - корпорация с кучей денег, имеющая весь мир, делающая ОС в интересах своих таких же бизнес-партнёров.
> Зато гугл взял и написал. И дрова будут.Зуб даёте? :)
> Одно дело какие-то nicheброды без денег и с GPL с хитрым простым
> как 3 копейки планом поиметь корпорации, а другое - корпорация
> с кучей денег, имеющая весь мир, делающая ОС в интересах своих
> таких же бизнес-партнёров.По-моему:
- план приписан (а по себе людей не судят);
- лучше быть нищeбродом, чем ницшебродом (вроде гугля).
>Зато гугл взял и написал. И дрова будут.1. Купил и дописал.
2. Дров не будет.
> В мире надёжности лучшеНе с того начали. Железо какое?
Почитай ради интереса про стоимость переключения контекста на x86. Просто чтобы быть в теме, почему не взлетели микроядра на x86.
И чтобы два раза не вставать, в SPARC совсем другая ситуация. Была, к сожалению, ибо SPARC уже всё.
С микроядрами все хорошо только на бумаге.
По факту же, как только все сводится к очередям и сообщениям, получаем либо однопоточность, либо глубокое погружение в дивный мир распределённых алгоритмов.
> Добавление специфичных оптимизаций, которые позволят снизить задержки в играх Google Stadia, могут повысить отзывчивость в конкретном случае, но скорее всего приведут к снижению эффективности планировщика в целом. Например, планировщик Windows ведёт себя лучше в обсуждаемых тестах, так как он значительно проще планировщика Linux и оптимизирован в основном для задач, специфичных для рабочего стола.Так может, так и надо делать? провести специфичную оптимизацию, вынести её в отдельный планировщик, а на серверах пусть крутится серверный.
Google Stadia — это и есть сервера.
к тому же вам уже скомпилировали вантуз. покупайте и пользуйтесь.
А может лучше игроделы под google stadia пусть научаться в spinlock?
Или используют что другое?
>А может лучше игроделы под google stadia«Stadia предлагает мгновенный доступ к игре без необходимости загружать или устанавливать какие-либо игры».
Сервис стал доступен 19 ноября 2019.Как заявляет компания, такая особенность позволяет подписчикам сервиса «стримить» игры на свои устройства в разрешении 4K с кадровой частотой 60 кадров в секунду.
Красавцы. И пофиг, что при передаче по сети "мгновенный доступ" будет мягко говоря не совсем мгновенным :)
А сделал вывод, что нам не хватает планировщика, для рабочего стола...
В оригинальном посте автор звукового сервера JACK сказал несколько дельных вещей, за это ему, автору поста, ck и автору новости - спасибо
Где всезнающий пох? Эй, пох! Ты всё знаешь, подскажи решение бытовой задачки:- как под уже установленную и работающую винду (WS2003 SP2 R2) подсунуть второй HDD и сделать «зеркало» (RAID-1) с первым HDD?
3,5-дюймовых дискеток, чтоб установить оффтопик по-правильному, к сожалению, нету ни одной, купить по-быстрому негде (пламенный привет поклонникам взрывного прогресса инноваций). Если в интерфейсе RAID-адаптера (встроенный в мамку Адаптек <че-то там>, могу посмотреть детальней, если надо, но не думаю, что это на самом деле кому-то надо) попытаться соединить диски в массив, оффтопик на мгновение показывает BSOD (?) и сразу отправляет мать на перезагрузку.
Если я руками положу внутрь уже установленной винды адаптековские дрова — она после перезагрузки их найдёт и свяжет с внезапно появившимся и ранее ей неизвестном массиве типа RAID-1? Или таки надо искать дискеты и всё делать заново по стандартной процедуре?
Нет, пингвиниксов на этом сервере я не хочу, фрю тоже не хочу.
> - как под уже установленную и работающую винду (WS2003 SP2 R2) подсунуть второй HDD и сделать «зеркало» (RAID-1) с первым HDD?https://www.sim-networks.com/wiki/create-software-raid-in-wi...
Как-то слишком просто такая задача на нормальных ос требует жестких плясок в консоли с бубном.
Недавно понадобилось. Тоже удивился.
Какие жесткие пляски, дети? Одна строчка в консоли. Одна, Карл!
А потом на загрузке будет у тебя mduuid not found и начинаются пляски)
Ты и в windows not found добьёшься, талант.
К сожалению, да. Под сервером Windows софтовый RAID без проблем конфигурируется после установки ОС. Под сервером Ubuntu нормальную установку софтового RAID (на этапе установки сервера) поломали, начиная с версии 16.04.3. Поэтому приходится ставить версию 16.04.2 для решения проблем, затем обновляться до актуальной 16.04 версии. То, что сделали в сервере, начиная с 18.04 версии, можно безобразием назвать - система нерабочая (в смысле софтового RAID).
ты не совсем прав. мы решили данную проблему. главное - вредные советы из интернета не читай.
Вы читать умеете? Человек хочет raid-1 после установки. Ты тут лепишь что-то про проблемы какого-то конкретного дистрибутива при _установке_. У вас что с причинно-следственными связями?
>> - как под уже установленную и работающую винду (WS2003 SP2 R2) подсунуть второй HDD и сделать «зеркало» (RAID-1) с первым HDD?
> https://www.sim-networks.com/wiki/create-software-raid-in-wi...В Windows 2003 такой функциональности нету в оснастке.
Тебе надо драйвер адаптека вручную поставить через управление компьютером/устройства. Когда поставишь указать что должен запускаться загрузчиком вместе с ядром
Тут подробнее как:
https://docs.microsoft.com/en-us/windows-hardware/drivers/if...
Потом перегружаешься делаешь рейд из биоса и все будет хорошо при загрузке. Винда напишет, что найдено новое устройство.Задачка-то элементарная, позор не знать.
Могу сказать на твой совет - он вреден (хотя адаптека немного обогатит). Посмотрю на тебя, когда сломается материнка сервера, а при этом сервер уникальный и лет 5-6 уже не выпускается. Софтовый RAID под любой системой от аппаратуры практически не зависит - перекидываем диски и понеслась. В худшем случае сетевой адрес прописать.
Вреден кому?
Я вопрошающему ответил, что ему делать надо, как понял его же вопрос.
Человек конретную проблему хочешь решить, ему видней надо адаптек или нет.
А что, разве остались еще контроллеры, не использующие DDF?
> Тебе надо драйвер адаптека вручную поставить через управление компьютером/устройства.
> Когда поставишь указать что должен запускаться загрузчиком вместе с ядром
> Тут подробнее как:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/if...
> Потом перегружаешься делаешь рейд из биоса и все будет хорошо при загрузке.
> Винда напишет, что найдено новое устройство.
> Задачка-то элементарная, позор не знать.Ну раз ты такой гуру… Давай-ка переформулирую. Винда во время загрузки показывает BSOD, если в адаптековском BIOS включить RAID. Просто включить, ага. Сообщение надо? Ну, на (я записал специально для тебя):
STOP: 0x0000007B(0xF789EA94,0xC0000034,0x00000000,0x00000000)Прояснилось? Не? ;)
Я хочу, чтобы винда перестала падать в BSOD, когда я пытаюсь просто включить RAID (и добавить в него второй HDD). Как это сделать?
Мне и раньше все было понятно и проблема твоя синим по белому написана, да вот ты написанному не внемлешь, балбес. Проблема твоя: не найден загрузочный диск, оно и неудивительно, ведь драйвера-то нет! :)
Еще раз: поставь драйвер, который нужен. Это дополнительный драйвер, не помню как у адаптека называется,fake-raid или еще как. Затем его надо включить в обязательный для загрузчика, что сложного?
Хорошо, если не понимаешь, то вот тебе второй способ, делаешь _новый_ _отдельный_ raid-1 из одного диска, перегружаешься, чтобы драйвер был поставлен как надо. Ставишь драйвер, если попросит (может и не попросить, так и будет неизвестное устройство). Теперь raid этот можно удалить и делать что собирался. Драйвер уже будет стоят как надо.
Фишка второго способа в том, что драйверы дисков всегда обязательные для загрузки на первой стадии ntldr, даже если диск не загрузочный.
Все это работает, мать его, для _любых_ таких случаев и кажись еще с windows 2000.
> Мне и раньше все было понятно и проблема твоя синим по белому
> написана, да вот ты написанному не внемлешь, балбес. Проблема твоя: не
> найден загрузочный диск, оно и неудивительно, ведь драйвера-то нет! :)
> Еще раз: поставь драйвер, который нужен. Это дополнительный драйвер, не помню как
> у адаптека называется,fake-raid или еще как. Затем его надо включить в
> обязательный для загрузчика, что сложного?Винда была установлена на отдельный винт, а не на массив, поскольку не было дискеты, дабы подсунуть ей драйвер. Всё работает, но как обычный ПК. RAID-функциональность отключена в BIOS контроллера, инача винду нельзя было установить. Хочется теперь подсунуть второй диск и сделать RAID-1. Для этого в прошивке контроллера требуется включить RAID-функциональность. Если её включить, винда валится в BSOD. Ещё раз, медленно: уже установленная винда видит загрузочный диск при любых настройках, но показывает BSOD, если попытаться включить RAID. Если выключить, снова всё работает в режиме ПК. Как сделать? Я не понимаю.
А дискеты для правильной установки — нету. Нету дискеты. Замкнутый круг. Будет дискета — не будет вопросов. :)
Еще раз, медленно: мне кристально ясно что у тебя не так. Если бы этот сервер был щас передо мной, понадобилось бы минут 5 (без учета времени на загрузку/пеерзагрузку), чтобы все сделать как надо.
Как работает гребаный fake-raid:
Биос (обычный ибо нет никакого контроллера на самом деле), если включен fake-raid, работает с дисками как с рейд компонентами и если рейд собран выдает его как обычный биос девайс. Казалось бы, че бы не работать, но вот беда, обычный сата драйвер в винде не найдет там MBR, потому что там вместо него метаданные рейда.
Потому загрузчик ntldr, втащив все дрова, каким полагается быть на _загрузке_ толкает ядро и дрова опрашивают все что видят и вуаля, драйвер сата диски видит, да MBR с них нечитается!
Итого все что надо сделать это драйвер fake-raid тот самый, который надо было на дискете пихать в самом начале, засунуть в систему и выставить правильный тип загрузки - вместе с загручиком.Аналогично если ты хочешь с фейкового рейда съехать на обычный сата, скорее всего достаточно будет скопировать диск побайтно и включить обычный IDE режим в биосе. Если хочешь как положено AHCI, то сюрприз, ahci драйвер в винде также по дефолту не загружается ntldr. :)
Все дело в долбанном типе загрузки драйвер.
Тоже самое веселье у эникев, которые поставили систему в IDE режиме контроллера, а потом включили AHCI, например потому что впихнули новенький SSD и оппаньки, тот же самый детский BSOD, что у тебя.
1. У меня SCSI, а не SATA. Перепиши свои умные советы с учётом этой досадной мелочи. ;)2. Синий экран я уже победил. Включил в БИОСе только канал B (на котором нет дисков) контроллера. Винда после загрузка нашла новое устройство и всосала нужный драйвер. Этот же драйвер принудительно скормил устройству канала A. Пара перезагрузок, между которыми в БИОСе включил RAID-функцию для канала А, и всё стало хорошо: ОС видит два RAID-контроллера (соответствуют каналам A и B).
3. Но массив не делается. Точнее, он делается, но после его постройки — прекрасный чорный экран с многообещающей надписью "Operating System Not Found".
Вопрос остаётся тот же: какие мне надо совершить манёвры, чтобы установить винду без дискеты с дровами, которой нету, но чтобы сделать зеркало уже после установки виндов?
ЗЫКонтроллер называет себя Adaptec Ultra320 SCSI AIC-7902B.
Я терпеливый человек, но у терпения предел есть и он заканчивается.
Какая разница между scsi и sata в данном случае? Проблема остается ровной той же самой, драйвер нужен на этапе загрузки. Я все расписал по этому поводу, как это работает. Больше по загрузке и драйверам распинаться не буду.
Хотя судя по пункту 2, ты таки справился. Рождественское чудо, не иначе.Маневры все теже. Причем если операция создания рейда была неразрущающей, то загрузчик и прочее должны быть в полном порядке. Здесь похоже достаточно порядок загрузки в биосе выставить верный.
Винда 2003 не умеет грузится не с 0 диска биоса.
Если все равно не выходит, то fixboot, fixmbr помогут.
Подробнее тут:
https://support.microsoft.com/en-us/help/326215/how-to-use-t...Если ты и после этих объяснений не справишься, то пора тебе подумать о смене профессии.
А консоль восстановления увидит диски в массиве? Попробуй подумать ещё разок. Не огорчай Даннинга и Крюгера, аноним. Попробуй читать, что пишут люди, а не заниматься копипастой общеизвестных банальностей из Гугла.Нет у меня дискеты. Понимаешь? Если бы дискета была, я бы этот драйвер подсунул винде по F6, как и положено.
Если ты не знаешь, как решить задачу, то проходи мимо. Денег нет, но вы держитесь, и всего вам хорошего.
Конечно увидит, если знать что делать. Зачем тебе дискета? Для того, чтобы консоль увидела диски надо добавить драйверы адаптек в образ и это совсем просто.
Но ты же только про Даннинга и Крюгера поговорить горазд, вместо освоения азов своей профессии.Наметки дал напоследок, авось справишься. Хотя врядли.
Адью.
> Конечно увидит, если знать что делать. Зачем тебе дискета? Для того, чтобы
> консоль увидела диски надо добавить драйверы адаптек в образ и это
> совсем просто.
> Но ты же только про Даннинга и Крюгера поговорить горазд, вместо освоения
> азов своей профессии.
> Наметки дал напоследок, авось справишься. Хотя врядли.
> Адью.Мальчик, ты дурак?
Впрочем, драйвер винде я таки подсунул. Попробую собрать диски в массив и после отпишу, что получилось.
Эту даже я до сих пор помню (а гугл и не забывал):
0x0000007B INACCESSIBLE_BOOT_DEVICEРешается вкручиванием правильного драйвера, как и написано выше.
В линухах модуль прикручивают к initrd(initramfs), и не всегда так уж тривиально (надо сначала выяснить мнение дистростроителей что куда класть). В винде суть процесса не меняется, но придётся освоить их терминологию и тулсет.
> 0x0000007B INACCESSIBLE_BOOT_DEVICEНет, синий экран у меня с другим сообщением. Я уже разобрался с синим экраном. Вопрос: что и как делать дальше.
> Решается вкручиванием правильного драйвера, как и написано выше.Выше ничего по существу-то и не описано, лишь копипаста банальностей.
Вкручивается драйвер либо со специально обученной дискеты во время установки, либо вшивается в дистрибутив до установки. Оба способа в моём случае не подходят. Какие есть ещё?
Вот смотри, что я имею на данный момент. Есть установленная (как для ПК) винда. Два диска подключены к контроллеру на один канал (A), но не собраны в RAID-1. Полностью и правильно установленная винда знает про рейд-контроллер и схарчила для него правильный драйвер. Что будет, если я в БИОСе контроллера попробую собрать массив?
> Вот смотри, что я имею на данный момент. Есть установленная (как для
> ПК) винда. Два диска подключены к контроллеру на один канал (A),
> но не собраны в RAID-1. Полностью и правильно установленная винда знает
> про рейд-контроллер и схарчила для него правильный драйвер. Что будет, если
> я в БИОСе контроллера попробую собрать массив?0. Смотрим что есть AIC-7902. Аппаратный u320-scsi (один из последних), так что про терминаторы на шине не забудьте. * И про оставшийся ресурс чипсета. Даже если он в столе валялся, есть смысл перешить. Окирпичится — туда и дорога.
1. Проверить (прочитать), куда контроллер кидает служебную инфу. Если в начало, то фокус обречён.
Но: надо ли так опасно? Что мешает сделать так:
2. Перевести имеющийся диск в режим jbod. Загрузиться (если нет, таки проблемы с драйвером, надо решить до продолжения).
3. Второй диск назначить raid0 или ещё как извратиться.
4. Смысл в том, что дальше туда dd (любой доступной тулзой побайтового копирования) слить данные первого диска. И пофиг тогда где там служебные сектора.
5. Дособрать raid1. Profit.* Это всё в предположении что винда грузится по uuid раздела. Я не знаю, как там работает загрузчик, так что советую проверить.
** В linux всё ±так же. Софтово — 3 (несовместимых) формата mdraid, 2 варианта lvm только на моей памяти. Аппаратно — сигнализацию в SAN (FC|iSCSI) местами надо вычитывать побайтно чтобы понять что за х*ня. Но инструментарий — доступнее.
В общем, я эту траблу победил без дискеты. По пунктам.1. В адаптековском BIOS отключил RAID-функциональность для канала A, но оставил включённой для канала B. Диски оба подключены к каналу A.
2. Установил по стандартной процедуре Windows 2003 и все драйверы для неё. Устройству SCSI-контроллера, соответствующему каналу A, принудительно установил тот же драйвер, что для SCSI-устройства канала B.
3. Включил обратно RAID-функциональность для канала A в BIOS контроллера.
(Тут в промежутке были ещё пара перезагрузок и узнавание виндой новых устройств, я поначалу решил об этом не писать, потому что вроде как само собой понятно, но всё же напишу.)
4. В BIOS адаптековского контроллера создал RAID-1 путём копирования диска 0 на диск 1.
4. Вуаля.
Выводы.1. Дискеты таки надо в хозяйстве иметь: понадобиться может один раз в десять лет, но когда понадобится — обыщешься.
2. Фейл моей предыдущей попытки произошёл из-за выбора в адаптековском меню разрушающего создания рейд-массива. «Что-то накатило…»
Скорее всего, я раньше куплю флопик и пачку дискет, чем дождусь дельного совета от опеннетовских икспердов. ;)
ЗЫИ отдельный аппаратный контроллер, а лучше два.
Никогда не используйте софтварный RAID в Windows(вне зависимости от реализации), то же самое и с "железным" без энергонезависимого кэша. Данные вы конечно не потеряете, но при каждом жестком выключении сервера вероятность "окирпичить" сервер даже выше, чем с одиночным диском, а восстановление будет долгим(примерно 2 часа на 500 гигабайт при условии что пользователи не залогинены, если залогинены, то и время увеличится и производительность дисковой системы будет едва ли десятая часть от нормальной).
Если мне нужно сделать бюджетный сервер под windows c софтовым RAID, то я обычно ставлю XEN + Debian с mdraid, windows с gplpv внутри виртуальной машины с пробростом томов lvm в качестве жесткого диска.
Плюсы:
- в mdraid восстановление имеет низкий приоритет, потому пользователи восстановление почти не замечают. При этом восстановление занимает столько же времени, сколько и восстановление softraid в Windows при наличии пользователей.
- производительность windows при использовании gplpv не намного ниже чем на реальном железе.
- нет проблем с драйверами, т. к. для windows эмулируется в старое железо, а притичные области перекрывают gplpv драйверы.
- есть возможность удаленно подключиться к консоли по VNC/SPICE в случае, если у Windows проблемы с запуском.
- есть возможность держать две виртуальных машины с windows, если для одной ресурсы сервера избыточны, или в моменты, когда нужно временно "пересадить" пользователей.
- исходя из двух последних можно переустановить винду удаленно.
- есть возможность использовать хостовую систему в качестве firewall/VPN/NAS.
Минусы:
- администраторы в филиалах боятся этого сервера - у него на мониторе черно-белая текстовая консоль.
- проброс USB-устройств сложноват, но в принципе тот же локальный hasp или консоль АТС работают, а для сетевого hasp есть демон.
- в редких случаях все же есть вероятность, что не загрузится linux.
- для использования видеоускорения нужно пробрасывать видеокарту с хостовой системы.
- gplpv - драйверы нужно удалять вручную и потом еще вычищать из реестра, в случае переноса на реальное железо.
> Никогда не используйте софтварный RAID в Windows(вне зависимости от реализации), то же
> самое и с "железным" без энергонезависимого кэша.Думаю, что ты стопроцентно прав, анонимный брат. Я уже в поиске подходящего железного сабжа с энергонезависимым кэшем.
> Данные вы конечно не потеряете,Уже потерял. По какой-то причине необратимо (?) деградировала файловая система. Поскольку на машине не было ничего критически жизненно важного, то инцидент не обернулся трагедией, но заставил задуматься.
Это каким образом вам удалось потерять данные с зеркала? Тома intel matrix/rapid видны из linux или например в acronis, данные можно спасти. в худшем случае придется повозиться с определением на каком из дисков зеркала актуальные данные.
> Это каким образом вам удалось потерять данные с зеркала? Тома intel matrix/rapid
> видны из linux или например в acronis, данные можно спасти.
> в худшем случае придется повозиться с определением на каком из дисков
> зеркала актуальные данные.Это отдельная история, но я счёл её малоинтересной для опеннетовского анонима. Впрочем, если спросили, то напишу. Данные потерялись в ходе операции «Очистка диска». Файловая система по какой-то причине начала разваливаться. Из двадцати, ЕМНИП, гигов файлов осталось около трёх. После перезагрузки винда не нашла свой hal.dll и ещё кучку нужных для себя файлов. Поскольку ничего существенного после этого на диски не писалось, то я вытащил то, что лежало в профиле юзера, и ещё кое-что сверху. Поскольку ничего такого уж важного на этой машине не было, то восстановление её данных не представляло значительного интереса.
ЗЫЧастично сломались файловые таблицы, если вкратце.
> игры выполняются на GPU в облачном окружении, а клиенту в потоковом режиме лишь транслируется содержимое экрана ... задержки, превышающие миллисекунду, становятся заметны.В гугл стали набирать на работу клоунов, причём целыми командами.
Наполеон ответил
А стадо баранов возглавляемое бараном? И по какой методике априорно производить оценку кто лев, а кто баран? А если оценку давать по результатам то какой смысл в этой фразе?
Тут, к сожалению, стадо баранов под руководством барана против законов физики.
Ну почему к сожалению, физике пофиг, бараны против ейных законов или единороги.
Фейл будет знатный :).
Еще один мудила из нижнего тагила пишет игры на ОС общего назначения. Dа на месте Линукса я бы ему с ноги голову втащил - козлу."... автор теста попытался возразить Линусу, указав на то, что применение собственных систем блокировки на базе spinlock часто используется на практике в играх, так ..."
На практике нужно взять систему реального времени (что-то на подобии существовавшего когда-то DOS/DMPI) и разрабатывать только одно приложение где нет планировщика процессов/потоков вообще. Вот и решение всех проблем современных игроделов, но даже большие игроделы такие слабаки в тех. плане, что не могут это уже который год сдлеать. Что Xbox сидит на Widnwos, что PS сиит на FreeBSD ядре. Слабаки.
Игры сейчас уже не те, они полагаются именно на поведение планировщиков. Вон даже в одноядерном режиме игры сейчас не работают, какое реальное время? Какое реальное время на 64 битах?
> На практике нужно взять систему реального времени (что-то на подобии существовавшего когда-то DOS/DMPI) и разрабатывать только одно приложение где нет планировщика процессов/потоков вообще.И сразу же пойти на SO с вопросом "как собрать проект Unity под DOS?"
Товральдс Мужик. Поставил зарвавшегося юнца на место.
Юнца поставил, молодец против овец.Зато против рыжего гремлина и своей дочурки он сам овца.
Вот здесь согласен. Батя толжен быть Батей прежде всего в семье, и ставить зарвавшихся дочyрoк на место, пока им окончательно не промыли мозги этими лгбт-ценностями. К сожалению, здесь Линус пpocрал время...
> негативно сказываются на работе игр, создаваемых для сервиса Google StadiaЧииго, бл*ть?? Вот нахрен мне это знать?))
Из всех сервисов гугла интересны только гмайл (больше по привычке), и поиск, из-за адекватно работающих операторов включения/исключения, которые в х*яндексе уже много лет как сломаны в угоду толпе. Все, остальное таак пофиг..
Зря ты так. Тут вообще хорошая идея в основе лежит. Идея в том, что срать на чем там все это написано, срать на чем оно там работает и какой там планировщик. Игра должна быстро работать и красиво рисовать, а ты только видеть картинку и управлять поведением.Отличная идея которая поставит всех игроделов перед серьезными вопросами выбора платформ и т.д. возможно даже что-то разработают под это дело полезное.
все там нормально в яндексе
Вот яркий пример того, что сейчас происходит и не только в гейдеве.
Вообще не знаю, что нас ждёт в будущем, когда такие, как Торвальдс, отойдут от дел.
В будущем тебе будет не до этого, чувак, гарантирую!)) Да даже в 2020ом..
> планировщик Windows ведёт себя лучше в обсуждаемых тестах, так
> как он значительно проще планировщика Linux и оптимизирован
> в основном для задач, специфичных для рабочего стола.Как будто десктоп - это что-то плохое.
> Линус возразил, что планировщик Linux является универсальным,
> оттачивался десятилетиями и оптимизирован не только для
> рабочего стола и игр, но и для других видов нагрузки, например,
> для серверных систем.А напаркуа мне "серверные системы" на домашнем компе?!
Выше в каментах правильно сказали - под десктопы, игры и сервера нужно делать разные планировщики, а не скрещивать ежа с ужом и потом хвастаться этим франкенштейном.
> А напаркуа мне "серверные системы" на домашнем компе?!Паркуатор, вырыгай кактус и одомашнивай комп.
Тебе никто ничего не обещал и не должен.
Ты мимикрокодил и интересен только корпорастам. Оплачивай хотелки. Или разработкой или дензнаками :)
Привет тебе от Коливаса :)
Один человека говорит что играть в футбол на траве гораздо удобнее в бутсах, а ему говорят что валенки гораздо универсальные. Все в них ходят они проверены годами при желании ты можешь даже сам их свалять. Так что помолчи юнец нам лучше знать.А он им валенки и игра в футбол на траве не совместимы. А ему такие чувак шипы приделывать к валенками это моветон. Да и кроссовки из валеной шерсти не удобные, мы эксперты мы лучше знаем. Учи матчасть нуб.
Погодите, но все кроме вас играют в футбол на траве в бутсах. А нам и в валенках тоже норм играть в футбол на траве. Универсально и проверено иди мальчик гуляй в своих бутсах, ты не эксперт.
Ну а что же тогда мешает играть в бутсах этому господину?
Так он играет в бутсах в другой системе, подходит к мистерам в валенках и говорит что в футбол надо в бутсах. А ему отвали юнец мы суровый интерпрайз нам только валенки. А если в футбол поиграть то тоже валенки. И не учи нас играть в футбол.
А На модном го и Данте если бутсы запилить - вообще все летать будет
> Один человека говорит что играть в футбол на траве гораздо удобнее в бутсах, а ему говорят что валенки гораздо универсальные. Все в них ходят они проверены годами при желании ты можешь даже сам их свалять. Так что помолчи юнец нам лучше знать.Не, ты неверно проводишь аналогию, если уж проводить, то было примерно так.
Один человек сказал, что в футбол на траве удобнее играть в бутсах, потому что в бутсах не страшен глубокий снег. А ему объяснили, что снегоизоляционные свойства бутс он мерял совершенно неправильно, и играть в бутсах на траве удобнее по несколько иным причинам.
Если же без аналогий, то чувак говорил, что мьютексы быстрее, чем спинлоки, поэтому надо использовать мьютексы в играх. Пришёл Торвальдс и объяснил ему, что в играх надо использовать мьютексы, а не спинлоки, но по несколько иным причинам.
Как же тогда футболисты играют на снегу в футбол в бутсах, а не в валенках? Бутсы есть и для снега и для льда и с изоляцией там все в порядке. Ваши Линусы и прочие иксперды в футбол на снегу то никогда не играли в бутсах. Да даже в валенках, сидят себе кодят света белого не видят.
> Как же тогда футболисты играют на снегу в футбол в бутсах,Ты уж определись, они играют в футбол на траве? Или в футбол на снегу?
Это ты начал про снег. А в футбол и на траве и на снегу бутсы то что доктор прописал. А ваш Линус просто не умеет в футбол вот и все.
> Это ты начал про снег. А в футбол и на траве и
> на снегу бутсы то что доктор прописал.Да, ты верно подметил. По обоим пунктам. Теперь тебе осталось подметить, что довольно странно доказывать, что валенки не подходят для футбола на траве из-за того, что бутсы лучше бегают по снегу. Когда ты поймёшь это, ты поймёшь чем моя аналогия отличается от твоей.
Единственная этом случае правильная аналогия это что в бутсах неудобно разгружать вагоны. А валенки и разгрузка вагонов проверенная годами связка.
Один человека говорит, что запускать компьютерные игры - это основная обязанность ОС компьютера.
Дальше можно дописать самостоятельно...
Я и сам раньше так думал)
Линус подтвердил что линукс - серверная ОС, которая не подходит для десктопа. Таким образом все кто портируют игры и десктоп-приложения на линукс по мнению Линуса - дэбилы. Тут сириус бизнес и энтерпрайз а не бирюльки.Ну это в принципе всё объясняет - и дизайн линукса, и нестабильный API, и крайне хреновую графическую подсистему, и убогую или отсутствуюущую поддержку устройств потребительского класса, и отсутствие обработки OOM, и тормоза при копировании с флэшки (12309), и многое другое. Всё это просто Линусу и интырпрайзу не нужно. Вам тут не десктоп, всего вам доброго и хорошего настроения.
Ты повторяешь мифы 20 летней давности, уже лет 15 как это всё не актуально.
Да я это у себя всё наблюдаю. Начиная со жрущей CPU как не в себя графики, кривой поддержки звука и видео, даже чёртов браузер умудряется работать хуже чем в винде. Браузер! Ну зато можно в одну команду поставить тридцать три сервера в тридцати трёх контейнерах. Так что кому что важнее.
а я такого у себя не наблюдаю
попробуйте докер и кубернетис с виртуалками удалить
тогда будет ок
> Начиная со жрущей CPU как не в себя графики, кривой поддержки звука и видео, даже чёртов браузер умудряется работать хуже чем в винде.хз ютуб работает ок и не лагает - комп ноут 10 летней давности, не жужжит
Это проблемы кривых браузеров, не хотят их разработчики они линукс за платформу считать. У хромиума получше — гугл продаёт девайсы с линуксом всё-таки.>жрущей CPU как не в себя графики
У нвидии всё норм что 15 лет назад, что сегодня.
>кривой поддержки звука и видео
Опять проблемы браузеров и криворуких кодеров. Я вот не использую пульсу и всё прекрасно. С видео у нвидии опять же всегда всё норм, загрузка процессора доли процента на 4к контенте. Теперь и bumblebee не нужен на лаптопах больше, вообще замечательно.
> Это проблемы кривых браузеров, не хотят их разработчики они линукс за платформу считать. У хромиума получше — гугл продаёт девайсы с линуксом всё-таки.Пользователю как-то всё равно с чьей стороны проблема. Если браузер хреново работает в данной ОС (а это 90% всего использования десктопа) - такая ОС ему не нужна. Пусть себе крутится на сервере.
> У нвидии всё норм что 15 лет назад, что сегодня.
К сожалению нет, по-крайней мере в ноутбуках. Теперь графику частично затащили в монолитное ядро и в сочетании с закрытым блобом система при багах в графике просто умирает. Даже не kernel panic, а просто хард лок с чёрным экраном. В лучшем случае падают иксы, но так как все пользовательские приложения - графические, то это вот как-то вообще не утешает. То что там продолжают крутится демоны при падении графики - это прикольно, но для пользователя десктопа бесполезно от слова совсем.
Проиграть полноэкранное видео без микро-лагов - проблема, подключить внешний телевизор - проблема, запустить игру - проблема (с этим стало получше, но далеко не везде без танцев с бубном работает). Да, можно с этим мириться как со жмущими ботинками, но это не нормальная и не здоровая ситуация.
>Опять проблемы браузеров и криворуких кодеров. Я вот не использую пульсу и всё прекрасно.
Пользователю как-то всё равно с чьей стороны проблема. Помню была где-то смешная проблема, что кодеры подсистемы звука под линукс признались что не могут решить проблему с несколькими звуковыми выходами на ноутбуках если у них одинаковые идентификаторы (например встроенные колонки и внешний аудио-выход). Так и писали - мол, мы таким не пользуемся, а если вам очень надо - вот вам язык и пишите сами себе кусок драйвера под свой ноутбук.
> Даже не kernel panic, а просто хард лок с чёрным экраном. В лучшем случае падают иксыА, то есть сейчас даже старый добрый сисрку комбинация не спасает? Только кнопкой питания исправлять ситуацию? Да это прогресс прям.
>Да я это у себя всё наблюдаю.Ваше мнение чрезвычайно важно участникам форума.
Продолжайте наблюдение...
Вот человек наблюдает, делится информацией, другие читают об этом, узнают, что не у всех всё хорошо работает. Возможно, для тех кто это читает, есть какая-то польза. А какая польза от вашего сообщения?
!!!ВОПРОС РИТОРИЧЕСКИЙ!!!
Если что-то плохо работает, об этом надо багрепорты писать.Но, конечно, если ни знания матчасти для анализа ситуации и выявления reproducible test case нет, ни знания английского, чтобы багрепорт сформулировать - тогда, да, все, что остаётся - это жаловаться на опеннетике в обществе таких же необразованных.
>Если что-то плохо работает, об этом надо багрепорты писать.Зачем вы пишите очевидные вещи? Это и так понятно!
>Но, конечно, если ни знания матчасти для анализа ситуации и выявления reproducible test case нет, ни знания английского, чтобы багрепорт сформулировать - тогда, да, все, что остаётся - это жаловаться на опеннетике в обществе таких же необразованных.
Спасибо, насмешили.
Винда 10 грузится минут 10 и тормозит
На линуксе загрузка меньше минутыПользователь hdd и старого компа с дуал бут
Апргрейдится не вижу смысла линукс работает вполне оперативно и стабильно
Можно попробовать отключить гибридную гибернацию или как её там у десяточки, так она и весь час грузиться будет. Не вижу смысла это обсуждать, как система линукс для пк куда больше подходит. Если в голове не совсем хлебушек, так он ещё и надёжней — не придётся регулярно переустанавливать, как виндоус. Впрочем, это зависит от дистра.
что за комп?в десятке надо сразу обязательно выключать "защитник" и не ставить другие "защитники" - этот говнософт сжирает вообще все ресурсы.
какойто 6 ядерный amd купленый лет 10 или больше назад 8gb памяти hdd дискзащитник отключен конечно - не помогает
"какойто 6 ядерный amd купленый лет 10 или больше назад 8gb памяти hdd диск"+ отключен "защитник".
и 10 минут загрузки? ты что-то делаешь не так. на core 2 duo с 4gb памяти и жестким на 7200 грузится гораздо быстрее.
Вообще одна из больших проблем винды - она не настроена изнанчально и настраивается хоть как-то только минимум в про версии через политики - внезапно, для дома ось проблематично использовать.
Ставь 1909 со всеми обновлениями. Всё что позже 15хх мсовцы разломали и только недавно привели хоть в какой-то порядок.
я редко загружаю windows 10
но когда это делаю - система всегда любезно предлагает обновится, сидишь потом пару часов и ждеж пока обновляетсяникаких улучшений в плане повышения производительности разумеется нет - да я не ожидаю этого
Линус подтвердил только то, что если хочешь написать правильный софт, учи документацию.
А ты подтвердил свою предвзятость, демагог :)
На самом деле Линус не объективен по этому вопросу и пытается давить авторитетом и руганью, а не разумными доводами. У него есть личное мнение и мнение это что локи в юзерспейсе - зло и "неправильно".Вот история 2002 года когда на попытку продвижение стандартных (на сегодня) фьютексов он так же плевался во всех:
https://yarchive.net/comp/linux/everything_is_file.html>You have a damn mutex system call, don't introduce mode crap in /dev.
Он достаточно долго вставлял палки в колёса и я подозреваю что именно поэтому в линуксе не было аналога критической секции из винды. Потом всем это видимо это надоело и сегодня фьютекс уже часть стандарта C++11. Впрочем Линус и плюсы ненавидит.
Как бы его не любили местные школьники он не раз показывал себя не с лучшей стороны и совсем не как профессионал. Он крайне, как говорится, opinionated и ему плевать на логику если у него есть Мнение по какому-либо вопросу.
чтоже мешает такой корпорации как google c немерянными бюджетами сделать все правильно - и сделать свой форк?
и раздавать и обновлять совершенно бесплатно эту чудесную правильную ось всем подписчикам google stadia абсолютно бесплатно и неограниченно в рамках действия срока подписки?
гуглу мешает авторитет Торвальдса, не иначе :)
Да ничего не мешает. Так же как они допатчили линукс до нужного им Android`а, так и сделают свою StadiaOS при необходимости. А Линус так и будет слюной брызгать.
что же они этого еще не сделали?сервис уже запустили вроде. но вместо того чтобы сделат ь как надо - пытаются найти виноватых в лице разработчиков ядра линукс.
На самом деле чувак перед тестами даже man не прочитал где всё это описано прямым текстом в разделе NOTES: http://man7.org/linux/man-pages/man3/pthread_spin_init.3.htmlАбсолютная некомпетентность.
А кто объективен? Анон с пoпeннета?
Гуглстадия там же и гуглгласс и еще миллион проектов от гугла
Линус определенно приложил к этому руку. То нвидии палец покажет, то гуглу вот таким изощренным методом. Не любит он большие корпорации почему то, ой не любит.
Гуглстадия... через год закроется, как 90% их проектов.
Как 146% скорее просто переименуют. А стриминг есть не только от гугла.
Нет. Закроют. Т.к. стримминговый сервис нужен, как корове пятое седло.
Вот когда вся сетевая инфраструктура перейдет на квантовую телепортацию, тогда стримминговые сервисы и взлетят. :-)
Нет
>Например, планировщик Windows ведёт себя лучше в обсуждаемых тестах, так как он значительно проще планировщика Linux и оптимизирован в основном для задач, специфичных для рабочего стола.пф, почему бы не распилить планировщик на два других?
даже такое хомоюзер, как я, и то сможет чекнуть нужную галочку в .конфиг либо скачать пакет ядра с нужным планировщиком.я сильно сомневаюсь, что хоум-юзеры линукса держат одновременно на домашних тачках серверные аппсы.
1. Монолит
2. Нафига?
Что ж, Линус пошёл в отрицание, закономерная реакция. Отзывчивость Линукса на десктопах все же страдает
Страдает, только проблема там совсем другая.