Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
Сообщение от opennews (??), 06-Янв-20, 10:21
Разработчик игр Malte Skarupke опубликовал сравнение производительности блокировок на основе Mutex и Spinlock при использовании различных планировщиков задач. Тесты показали аномально большие задержки при использовании Spinlock с по умолчанию используемым в Linux планировщиком задач. Автор тестов сделал вывод, что планировщик задач Linux имеет проблемы, которые негативно сказываются на работе игр, создаваемых для сервиса Google Stadia, в котором игры выполняются на GPU в облачном окружении, а клиенту в потоковом режиме лишь транслируется содержимое экрана с частотой до 60 кадров в секунду. При подобных условиях необходимо обеспечить своевременный вывод кадров на экран и задержки превышающие миллисекунду становятся заметны... Подробнее: https://www.opennet.me/opennews/art.shtml?num=52140
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+23 +/–
Сообщение от Аноним (2), 06-Янв-20, 10:23
Ничего не понял из текста, но я более за Линуса. гугл в утиль.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от Аноним (2), 06-Янв-20, 10:24
	*болею (извиняюсь, опечатка)
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+73 +/–
	Сообщение от iPony129412 (?), 06-Янв-20, 11:11
	Выздоравливай 🤒
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от Аноним (2), 06-Янв-20, 16:49
	Спасибо, только насморк остался ещё
	Ответить | Правка | Наверх | Cообщить модератору

	379. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Baz (?), 08-Янв-20, 14:38
	держи лекарство от Линуса - FuckUoyNvidia.png
	Ответить | Правка | Наверх | Cообщить модератору

	386. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от ммнюмнюмус (?), 08-Янв-20, 22:31
	Не забудьте специально для него заточенные салфетки Клинюкс
	Ответить | Правка | Наверх | Cообщить модератору

	6. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 10:43
	> Ничего не понял из текста, но я более за Линуса. гугл в > утиль. Спинлок, грубо говоря, это пустой цикл, выполняемый с целью задержки. Если открыть руководство по разработке для ОС с "более простым планировщиком, чем в Linux" -- там такое можно найти в разделе "модули ядра" и с оговоркой про IRQL (нет смысла объяснять, что это -- для разработчиков игр оно неведомо).
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	164. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+10 +/–
	Сообщение от Урри (?), 06-Янв-20, 17:27
	Эммм, что за херню вы принесли и какие идиоты вас плюсанули?? Цель спинлоков - не задержка выполнения программы, а быстрая проверка некоторого условия (например и чаще всего, захваченности мьютекса) в юзерспейсе без переключения в кернелспейс (которое довольно дорого по ресурсам). Используется для снижения использования вычислительных ресурсов в случаях, когда ожидаются частые захват+освобождение того же мьютекса, например. Любые программисты (не обезьяны, а программисты) в курсе что такое спинлок и нахера он нужен; даже на всех собеседованиях (на позицию программиста, а не обезьяны) об этом спрашивают.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (6), 06-Янв-20, 18:13
	> Эммм, что за херню вы принесли и какие идиоты вас плюсанули?? > Цель спинлоков - не задержка выполнения программы, а быстрая проверка некоторого условия > (например и чаще всего, захваченности мьютекса) в юзерспейсе без переключения в > кернелспейс (которое довольно дорого по ресурсам). Это называется побочный эффект (алгоритма). А кто не принимает во внимание, что сам алгорим -- тупой цикл -- тот потом и получает от Линуса советы. > Используется для снижения использования вычислительных ресурсов в случаях Да-да. Бывает, здорово снижает. Вместо пары переключений контекста -- мульён итераций у особо одарённых.) > когда ожидаются > частые захват+освобождение того же мьютекса, например. > Любые программисты (не обезьяны, а программисты) в курсе что такое спинлок и > нахера он нужен; даже на всех собеседованиях (на позицию программиста, а > не обезьяны) об этом спрашивают. Спрашивающий, очевидно, от этого далёк, развёрнутое объяснгение лишь запутает, потому было заменено на оговорку "грубо говоря".
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Урри (?), 06-Янв-20, 18:45
	> сам алгорим -- тупой цикл (facepalm) Охохохохо... Спинлок - это не тупой цикл. Это давно-давно, еще когда динозавры жили, придуманный примитив синхронизации, который в первую очередь требует эксклюзивного доступа к некоему ресурсу (обычно - ячейке памяти, обычно - lock на шину при доступе к ней) и который, уже во вторую очередь, является циклом (как и 99,999% любой компьютерной программы). Причем, желательно, чтобы никаких итераций этого цикла не было вовсе. Спинлоки как раз используют тогда, когда ожидают, что ресурс будет в основном свободен. Вот в чем смысл спинлока, безграмотный аноним, а не в бездарном бегании по кругу. > Да-да. Бывает, здорово снижает. Вместо пары переключений контекста -- мульён итераций у особо одарённых.) Сдуру можно и буй сломать. Естественно, спинлоки надо правильно использовать - вы же не чистите зубы шариковой ручкой? > Спрашивающий, очевидно, от этого далёк, развёрнутое объяснгение лишь запутает, потому было заменено на оговорку "грубо говоря". Ваше "развернутое объяснение" оказалось совершенно ошибочным. Если вы сами не знаете предмета разговора, то лучше промолчать, чем вводить вопрошающего в заблуждение.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (6), 06-Янв-20, 19:35
	>[оверквотинг удален] > (facepalm) Охохохохо... > Спинлок - это не тупой цикл. Это давно-давно, еще когда динозавры жили, > придуманный примитив синхронизации, который в первую очередь требует эксклюзивного доступа > к некоему ресурсу (обычно - ячейке памяти, обычно - lock на > шину при доступе к ней) и который, уже во вторую очередь, > является циклом (как и 99,999% любой компьютерной программы). > Причем, желательно, чтобы никаких итераций этого цикла не было вовсе. Спинлоки как > раз используют тогда, когда ожидают, что ресурс будет в основном свободен. > Вот в чем смысл спинлока, безграмотный аноним, а не в бездарном > бегании по кругу. Я понимаю, что некоторые динозавры до сих пор не знают, что такое побочный эффект. Это собственно то, ради чего алгоритм, в данном случае - тупой цикл без полезной работы, выполняется. Случается, что таких эффектов несколько. В данном случае эффектом оказался вовсе не тот, о котором ты с таким апломбом написал. Такой вот наблюдаемый результат. >> Да-да. Бывает, здорово снижает. Вместо пары переключений контекста -- мульён итераций у особо одарённых.) > Сдуру можно и буй сломать. Естественно, спинлоки надо правильно использовать - вы > же не чистите зубы шариковой ручкой? Ну вот сломал один. Линус ему объясняет, в чём дело. Тебе ситуация из новости ни о чём не говорит? Мне очевидно, что ты мог бы всё это адресовать тому критику Линукса, было бы больше пользы. Он ведь тоже думает, что у него там "вот счас быстренько проверим свободный ресурс". >> Спрашивающий, очевидно, от этого далёк, развёрнутое объяснгение лишь запутает, потому было заменено на оговорку "грубо говоря". > Ваше "развернутое объяснение" оказалось совершенно ошибочным. Если вы сами не знаете предмета > разговора, то лучше промолчать, чем вводить вопрошающего в заблуждение. Хочешь сказать, что я напрасно сделал оговорку "грубо говоря", после того как сам же и потратил столько времени на её развёртывание?)))
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+12 +/–
	Сообщение от erthink (ok), 06-Янв-20, 18:31
	Стоит уточнить/усугубить, что в linux (в современной glibc) mutex'ы реализованы через futex'ы aka benaphor'ы. Суть же фьютекса в том, что это просто word в userspace, над которым выполняются interlocked/atomic  операции с syscall'ом в slow-path. Соответственно, если такой мьютекст свободен и его никто не ждет, то стоимость его захвата/освобождения такая-же как у spinlock'а. Сискол же будет когда потребуется ожидание при захвате, или для пробуждения других процессов при освобождении.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	333. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от letsmac (ok), 07-Янв-20, 13:06
	>>Цель спинлоков - не задержка выполнения программы, а быстрая проверка некоторого условия (например и чаще всего, захваченности мьютекса) в юзерспейсе без переключения в кернелспейс (которое довольно дорого по ресурсам). ИМХО это просто костыль оставшийся от лени делать программные прерывания. Асинхронность можно сделать и без вызова ядра.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	411. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от ПриветКолян (?), 09-Янв-20, 19:27
	Захваченности чего? Mutex нельзя захватить. Это просто сигнализирующий механизм. Вывеска на двери номера "Сейчас я трахаю Машу. Дырка занята, заходите позже".
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	414. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от КО (?), 13-Янв-20, 15:22
	Захватить это и есть вывесить вывеску на пустую дверь. Кто первый тот и папа. Другое дело, что смешались в кучу кони, люди... Один из способов захвата и называется спинлок.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+12 +/–
	Сообщение от vitalif (ok), 06-Янв-20, 14:21
	Ага, ну да, конечно, у Штадии проблемы из-за плохого планировщика в линуксе, а совсем не из-за сетевой задержки. Да-да...
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	93. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
	Сообщение от Аноним (93), 06-Янв-20, 14:22
	Из такого вольного пересказа Я бы тоже ничего не понял. Читайте ответ Линуса в оригинале. Вкратце, чувак сам не понял, что он измеряет.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	114. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+11 +/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:09
	Ага.  Мне особенно приглянулись вот эти кусочки: > 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: интересно, индусы успеют захавать гугль?
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (157), 06-Янв-20, 17:12
	Уже)
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (209), 06-Янв-20, 19:42
	В руководстве американских корпораций сплошные Лингамапутры с цыганскими методами.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	287. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от axredneck (?), 07-Янв-20, 00:22
	> "на пальцах" На скольких и на каких?
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	380. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от InuYasha (?), 08-Янв-20, 14:48
	Старый Суровый Линус, я бы сказал )
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	140. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (140), 06-Янв-20, 16:25
	> Ничего не понял не понял - не пиши сюда.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	207. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (207), 06-Янв-20, 19:37
	"Вы просто неправильно их используете!"
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	329. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от заминированный тапок (?), 07-Янв-20, 12:15
	всё очевидно же: очередной смyзихлёб в зауженных тениках прострелил себе ногу (не разбираясь досконально в теме) и кричит простреленную ногу "р3шето"
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	348. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (348), 07-Янв-20, 17:48
	"Я ничего не понял, но я за Торвальдса". Кичишься своим невежеством, и ещё +50 себе накрутил? Вот чудак. А тем временем, в комментариях есть хорошие комменты, например о том, что автор сервера JACK отписался в комментах, а также толковый коммент с обзором шедулёров в Windows.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	359. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от JL2001 (ok), 07-Янв-20, 21:15
	> А тем временем, в комментариях > есть хорошие комменты, например о том, что автор сервера JACK отписался > в комментах, а также толковый коммент с обзором шедулёров в Windows. а чего ж ссылки то не дали?
	Ответить | Правка | Наверх | Cообщить модератору

	387. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Kuromi (ok), 08-Янв-20, 23:28
	А что тут непонятного-то? Разработчики игр и околоигровая братия считают, что Линус должен немедленно начать оптимизировать ОС под специфические игровые задачи, особенно когда некоторые компании вроде Гугл собирались зарабатывать на этом большие деньги. Линус ответил, что не одними играми мир мазан.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	393. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Тот_Самый_Анонимус (?), 09-Янв-20, 06:22
	>Ничего не понял из текста, но я более за Линуса. гугл в утиль. Мужик! Я нихера не понял, что ты сказал мне, но ты мне близок. Ты заговорил, и достучался до сердца. (Джей и Молчаливый Боб Наносят ответный удар) Это и называется фанатизмом: следование решению партии без вникания в суть.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

4. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+7 +/–
Сообщение от Нанобот (ok), 06-Янв-20, 10:24
Линус Торвальдс опустил диванного эксперта
Ответить | Правка | Наверх | Cообщить модератору

	25. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–26 +/–
	Сообщение от Аноним (25), 06-Янв-20, 11:20
	Линусу или пора опять в отпуск, подумать над своим поведением , или он обратно отрастил свои стальные CoC`и ? =D
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+30 +/–
	Сообщение от Аноним_t (?), 06-Янв-20, 11:41
	Линусу повезло, что "эксперт" не трансвестит или что-то вроде.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (109), 06-Янв-20, 15:03
	Захочет отомстить — сменит. Gamergate v2.0 пока что не исключён.
	Ответить | Правка | Наверх | Cообщить модератору

	412. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от ПриветКолян (?), 09-Янв-20, 19:31
	Ой ли.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	38. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (38), 06-Янв-20, 11:56
	Реально жесть! Смотреть до конца!
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	94. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (94), 06-Янв-20, 14:24
	Как будто игроиндустрии бывают какие-то другие.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. Скрыто модератором	–12 +/–
Сообщение от Аноним (5), 06-Янв-20, 10:29
Опять выгораживает Инго Молнара, как и 10 лет назад. Всё-таки неудивительно, что Финляндия когда-то была частью России: у Линуса явно есть принцип "да, он конечно не прав - но он же СВОЙ, а СВОЕГО надо защищать любой ценой". Думаю, вы часто наблюдали такое в нашей стране Вопрос знатокам: как там MyQSS?
Ответить | Правка | Наверх | Cообщить модератору

	22. Скрыто модератором	+11 +/–
	Сообщение от Анонимышь (?), 06-Янв-20, 11:16
	> Опять выгораживает Инго Молнара, как и 10 лет назад. Всё-таки неудивительно, что > Финляндия когда-то была частью России: у Линуса явно есть принцип "да, > он конечно не прав - но он же СВОЙ, а СВОЕГО > надо защищать любой ценой". Думаю, вы часто наблюдали такое в нашей > стране Я тебя разочарую, но эта(точнее похожая) фраза была сказана(и стала 'крылатой') американцем.
	Ответить | Правка | Наверх | Cообщить модератору

	349. Скрыто модератором	+1 +/–
	Сообщение от Аноним (348), 07-Янв-20, 17:51
	> Вопрос знатокам: как там MyQSS? В оригинальном англоязычном посте дан ответ. В первом же абзаце пишут, что с ним тоже плохо.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

7. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
Сообщение от anonymous (??), 06-Янв-20, 10:46
Хм, неожиданно. Много лет использую spin lock-и в местах, где lock очень короткий и получаю прирост в производительности, как и в синтетических тестах, так и по метрикам production-а. А тут, выясняется, что сам Линус говорит, что spin lock-и использовать нельзя.
Ответить | Правка | Наверх | Cообщить модератору

	10. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+8 +/–
	Сообщение от Аноним (6), 06-Янв-20, 10:50
	> Хм, неожиданно. Много лет использую spin lock-и в местах, > где lock очень > короткий Важная деталь. > сам Линус > говорит, что spin lock-и использовать нельзя. "использовать с большой осторожностью и полностью разбираясь в деталях"
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от anonymous (??), 06-Янв-20, 11:32
	>> сам Линус >> говорит, что 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 достаточно короткий, то такое бывает очень редко, и в среднем будет (и есть) сильный выигрыш. Не очень понимаю, почему Линус так сказал...
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+6 +/–
	Сообщение от anonymous (??), 06-Янв-20, 11:41
	> то такое бывает очень редко Из-за этого редко некоторые игры на Stadia лагают, поэтому Линус ему так и ответил что он **** и не разбирается в том, как работает spinlock на ОС без realtime scheduling-а. Вот и весь посыл, а ещё он сказал что всё что намерил разработчик - мусор. И правильно сказал, ибо в контексте, в котором пишет разработчик Stadia, оно мусором и является.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от колба (?), 06-Янв-20, 14:18
	а разве мерил разработчик стадии? там вроде какой-то левый чувак вобще..
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
	Сообщение от Аноним (6), 06-Янв-20, 11:53
	> я всё это время использовал spinlock-и неправильно Не так что бы всё. Точнее можно оценить из соотношения времён взятия спинлока и длительности кванта планировщика. > и является пищей для размышления ИМХО именно с такой целью Линус и высказался. Это примерно как в детстве учат: "не суй пальцы в розетку". Потом преподают закон Ома и так далее. Кто-то идёт в электрики, кто-то -- атомные электростанции строить. А некоторым и к старости нечего пальцы в розетку сувать.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	120. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:14
	> Это примерно как в детстве учат: "не суй пальцы в розетку". Ой да.  Единственно что дополню: по упорным типа меня лучше работало "сунешь пальцы в розетку -- долбанёт так, что мало не покажется".  Чтоб когда всё-таки долбанёт, было над чем задуматься и попробовать выяснить, а они-то откуда заранее знали... То есть от неоправданных догматов переходить к пониманию происходящего. PS: а то розетка-то может быть обесточенной, "догмат" пострадает (и в следующий раз может не спасти своего носителя), поскольку был неверен изначально -- а понимание подскажет, почему пронесло.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (190), 06-Янв-20, 18:51
	Миша, ты на праздниках перебрал, что-ли? Уносит тебя куда-то не туда...
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
	Сообщение от Аноним (6), 07-Янв-20, 08:06
	Иду я и вижу: человек дотронулся до трансформаторной будки, его бьёт током. Среагировал как положено, подручным предметом из диэлектрика разомкнул цепь. -- Попал мне камушек в сандаль. Я рукой об эту штуку опёрся, ногой потряс, и тут этот ошалелый меня как огреет доской!
	Ответить | Правка | Наверх | Cообщить модератору

	417. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Cadet (?), 13-Янв-20, 19:00
	>в детстве учат: "не суй пальцы в розетку" А я сунул. Точнее за оголенные провода специально взялся. Нехило так потом руку колотило.
	Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

	87. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от колба (?), 06-Янв-20, 14:16
	это говорит о том что вы не до конца понимаете как работает спинлок, но вам повезло и вы не получили от этого негативных последствий( либо не заметили их)
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	239. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (239), 06-Янв-20, 21:40
	Правильный быстрый lock должен быть как критические секции в винде. В случае промаха захвата ресурса нужно уйти ждать объект ядра, предварительно поставив флаг заставляющий при освобождении ресурса отправить уведомление ядру. В таком случае при переключении контекста блокировавшего потока(если уж случилось) ожидающие этот же ресурс потоки не будут мешать блокирующему ресурс потоку вернуться к выполнению. То есть займёт меньше времени.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	208. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (207), 06-Янв-20, 19:39
	"Вы просто неправильно их используете!"
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	35. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+13 +/–
	Сообщение от Аноним_t (?), 06-Янв-20, 11:45
	> Много лет использую spin lock-и в местах, где lock очень короткий и получаю прирост в производительности, как и в синтетических тестах, так и по метрикам production-а. На коротких спинлоках статистически ты выигрываешь. Но изредка возможны (относительно большие) задержки, в тех случаях, когда твой спинлок был прерван перепланировкой. Тебя это устраивает, а игроделов - нет.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	57. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от псевдонимус (?), 06-Янв-20, 12:51
	А ещё он говорил что обычный юзер имеет право менять системное время на хосте...много чего он говорил.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	82. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от rvm1975 (?), 06-Янв-20, 14:04
	в php коде ?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	112. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Egan (?), 06-Янв-20, 15:06
	Имхо костыль. Что конкретно Вы этим костыляете - сказать затрудняюсь, но я бы не назвал это нормальной практикой.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	117. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:11
	Тогда на всякий напомню его же подобное по стилю разъяснение о том, почему PAE использовать не надо совсем вообще никогда нигде, а системам с более чем гигабайтом (даже не двумя) памяти показана 64-битная адресация: http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-abo.../
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	161. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Anonymoustus (ok), 06-Янв-20, 17:18
	> Тогда на всякий напомню его же подобное по стилю разъяснение о том, > почему PAE использовать не надо совсем вообще никогда нигде, а системам > с более чем гигабайтом (даже не двумя) памяти показана 64-битная адресация: > http://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-abo.../ Эта статья вызывает мегатонны фейспалмов и показывает, что бестолковость Торвальдса лишь немного меньше бестолковости среднего опеннетовского анонима.
	Ответить | Правка | Наверх | Cообщить модератору

	389. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Kuromi (ok), 08-Янв-20, 23:38
	А разве где-то память через PAE реально использовалась? Самый реальный пример который мне опадался - сторонний драйвер RAM-диска который был способен организовывать диск в PAE области. Так чсебе применение, но всеж таки. В куда большем числе случаев PAE включался просто чтобы использовать NX-бит.
	Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

	396. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от КО (?), 09-Янв-20, 10:22
	В том же Oracle RDBMS в стародавние времена в качестве кеша. И прочих программах которым нужно было много памяти. На текущий момент при выборе новой системы - действительно не актуально.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (195), 06-Янв-20, 18:58
	> Хм, неожиданно. Много лет использую spin lock-и в местах, где lock очень > короткий и получаю прирост в производительности, как и в синтетических тестах, > так и по метрикам production-а. А тут, выясняется, что сам Линус > говорит, что spin lock-и использовать нельзя. Строго говоря, Линус говорит, что их ненужно использовать, если вы точно не знаете как надо, чтобы было не больно, а то будет ай-ай-ай!
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	351. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Сергей (??), 07-Янв-20, 18:07
	> прирост в производительности This. У него "прирост производительности" aka "Average test duration" на спинлоках в линуксе тоже виден, почти на всех шедулерах. Но его же интересует задержка, aka "Four longest idle times" - что даже не 99 перцентиль.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	356. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Forth (ok), 07-Янв-20, 20:46
	Если чувака интересует только задержка, что из переписки не очевидно, то он явно пользуется спинлоками неправильно. Политика SCHED_OTHER ему не подходит в таком случае, для этого есть SCHED_FIFO.
	Ответить | Правка | Наверх | Cообщить модератору

	398. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от КО (?), 09-Янв-20, 10:27
	>Если чувака интересует только задержка, А всякие starvation и проблемы с перегруженным процессором его не колеблют, то да чем проще цикл spinlock - тем эффективней. Если рояет что-то другое, то и инструмент надо выбирать другой.
	Ответить | Правка | Наверх | Cообщить модератору

	415. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от КО (?), 13-Янв-20, 15:25
	Вообще-то он про другое говорит. В основном про методику измерения времени задержки, которая показывает, что иногда, при вытесняющей многозадачности, случаются моменты окончания выделенного кванта времени. И сравнивать скорость захвата, по тому где в коде это происходит дело не благодарное.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

8. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
Сообщение от Аноним (8), 06-Янв-20, 10:47
Если на MuQSS не будет провала (а я подозреваю что это так), то прав совсем не Линус
Ответить | Правка | Наверх | Cообщить модератору

	23. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от anonymous (??), 06-Янв-20, 11:17
	По такой же логике можно обвинить компилятор, если программа не работает, когда на самом деле она не работает из-за UB (мол "на другом-то компиляторе всё good!").
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–5 +/–
	Сообщение от Аноним (8), 06-Янв-20, 12:48
	Челюсть ставишь, что без спинлоков на CFS будет быстрее? Или просто так ляпнул, авось за умного сойти?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (6), 06-Янв-20, 13:53
	> Челюсть ставишь, что без спинлоков на CFS будет быстрее? Или просто так > ляпнул, авось за умного сойти? Это ты челюсть поставил вот этой заявой и предположениям выше про MuQSS. Так что ждём от тебя результатов и сорцов для повторения тестов (ты ведь не будешь подгонять цифирки, просто -- так принято).
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–4 +/–
	Сообщение от Аноним (8), 06-Янв-20, 14:48
	Поздравляю, Шарик, ты балбес. Иди чекни статью по оп ссылке
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (6), 06-Янв-20, 15:14
	Тебе надо, ты и иди. Заодно челюсть спасёшь.
	Ответить | Правка | Наверх | Cообщить модератору

	325. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от anonymous (??), 07-Янв-20, 11:07
	Я предпочитаю просто обсуждать вопрос в плоскости логики и/или ссылок на факты. "Челюсть" не буду "ставить" в любой дискуссии.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	231. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (231), 06-Янв-20, 21:01
	Тут сразу вспоминается история с memcpy(), glibc и adobe flash
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	364. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от JL2001 (ok), 08-Янв-20, 00:03
	> Тут сразу вспоминается история с memcpy(), glibc и adobe flash а что там было?
	Ответить | Правка | Наверх | Cообщить модератору

	395. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 09:27
	я так понимаю, имеется в виду вот это: https://www.linux.org.ru/news/linux-general/5545961
	Ответить | Правка | Наверх | Cообщить модератору

	394. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 09:26
	Сложно сказать, как в этом случае. Возможно в данном случае Линус прав: не понимаешь что это и как его правильно использовать - не используй. С memcpy(), имхо, он был не прав, причём по аналогичной логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся безопасным и более медленным memmove()-ом.
	Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

	399. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от nobody (??), 09-Янв-20, 13:29
	Нет. В тот раз проблема была в навязывании всем: "Есть дураки, которые не понимают чем memcpy() отличается от memmove(), поэтому давайте будем считать дураками всех и отберём memcpy() у ВСЕХ"
	Ответить | Правка | Наверх | Cообщить модератору

	401. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 15:15
	> Нет. В тот раз проблема была в навязывании всем: "Есть дураки, которые > не понимают чем memcpy() отличается от memmove(), поэтому давайте будем считать > дураками всех и отберём memcpy() у ВСЕХ" Ну так, к сожалению, Линус такое и предлагает в https://bugzilla.redhat.com/show_bug.cgi?id=638477#c101 I'd personally suggest that glibc just alias memcpy() to memmove(). И в этом я с ним не согласен.
	Ответить | Правка | Наверх | Cообщить модератору

	402. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от nobody (??), 09-Янв-20, 15:20
	А я что написал?..
	Ответить | Правка | Наверх | Cообщить модератору

	404. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 15:39
	> А я что написал?.. Прошу прощения, значит я неправильно понял Ваш посыл.
	Ответить | Правка | Наверх | Cообщить модератору

	403. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 09-Янв-20, 15:33
	> Сложно сказать, как в этом случае. Возможно в данном случае Линус прав: > не понимаешь что это и как его правильно использовать - не > используй. С memcpy(), имхо, он был не прав, причём по аналогичной > логике - не понимаешь, чем отличается memmove() от memcpy() - пользуйся > безопасным и более медленным memmove()-ом. Прошу прощения за свою лень, напишу, не смотря в исходники. В упомянутых функциях уже столько проверок, что ещё одна мало что изменит.
	Ответить | Правка | К родителю #394 | Наверх | Cообщить модератору

	405. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 15:49
	>> Сложно сказать, как в этом случае. Возможно в данном случае Линус прав: >> не понимаешь что это и как его правильно использовать - не >> используй. С 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 как можете видеть, разница таки есть. как минимум в анализе перекрытия областей и прочей математики, для обеспечения копирования "назад".
	Ответить | Правка | Наверх | Cообщить модератору

	406. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 09-Янв-20, 16:09
	> простая "I'd personally suggest that glibc just alias memcpy() to memmove()." В glibc она не такая простая, насколько помню, там есть выбор от размера копируемых данных. А если добавить проверку перекрытия в простой код: на больших объёмах не играет роли; на малых memcpy() не эффективна.
	Ответить | Правка | Наверх | Cообщить модератору

	407. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 16:22
	>> простая > "I'd personally suggest that glibc just alias memcpy() to memmove()." > В glibc она не такая простая, насколько помню, там есть выбор от > размера копируемых данных. А если добавить проверку перекрытия в простой код: > на больших объёмах не играет роли; на малых memcpy() не эффективна. Не могу с Вами, как и с Линусом, согласиться. На малых и известных на этапе компиляции объёмах, при соответствующем уровне оптимизации, gcc может заменить memcpy() на свой код, который копирует как memcpy() (разворачивается в последовательность команд mov). По крайней мере я такое точно наблюдал в своих проектах. На больших объёмах - да, лишние потери будут меньше, но всё-равно будут. А если это какой-нибудь там Intel Atom с тактовой частотой 400MHz? Не везде можно, и оправдано, ставить самый распоследний 32-х ядерный, или какой там сейчас самый топовый, Intel Xeon с сотнями гигабайт памяти ОЗУ.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 09-Янв-20, 16:35
	>>> простая >> "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.
	Ответить | Правка | Наверх | Cообщить модератору

	409. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Совершенно другой аноним (?), 09-Янв-20, 16:49
	> С моей точки зрения такое объединение нежелательно по другой причине: поощряет пофигизм > при написании кода и нарушает переносимость на другие ОС и libc. Тоже думал про такой аспект, но забыл написать.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (41), 06-Янв-20, 12:04
	Независимо от результатов с muqss, это не противоречит словам Линуса, просто потому что этот планировщик как раз неуниверсален и разрабатывается исключительно для десктоп систем. Есть мир за пределами рача на твоём ноутбуке
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	55. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (8), 06-Янв-20, 12:47
	Где-то тут должна была быть логика, но она не обнаружена. Зачем мне планировщик, который не оптимизирован под мои задачи, на моём ноутбуке? Для понтов?
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 14:05
	а кто сказал что он не оптимизирован? зыж и да — кто не обнаружил логику?
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (8), 06-Янв-20, 14:49
	Он переоптимизирован настолько сильно, что стал работать медленнее? Ок
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 15:21
	враньё
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (133), 06-Янв-20, 15:41
	Поддерживаю. В чем смысл одного универсального, но менее эффективного планировщика? Легче сопровождать? Лень? Ну, собственно ничего нового.  Линуксу фиолетово на десктоп, ясень пень.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	217. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (109), 06-Янв-20, 20:23
	> Поддерживаю. В чем смысл одного универсального, но менее эффективного планировщика? Легче сопровождать? Лень? А какие ОС нынче имеют несколько специализированных планировщиков, не просветите?
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (109), 06-Янв-20, 20:26
	> Где-то тут должна была быть логика, но она не обнаружена. Зачем мне планировщик, который не оптимизирован под мои задачи, на моём ноутбуке? Для понтов? Не хочу вас расстраивать, но под персонально ваши задачи не будут оптимизировать свой планировщик ни в одной из существующих операционных систем. Поэтому извольте давиться тем, что дают.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	237. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 21:31
	>Зачем мне планировщик, который не оптимизирован под мои задачи, на моём ноутбуке? Для понтов? >Где-то тут должна была быть логика, но она не обнаружена. А ты забавный. Понтов дофига и прям все тебе должны. Мы тебя прощаем, пакуйся с миром.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	89. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–12 +/–
	Сообщение от zzz (??), 06-Янв-20, 14:19
	Виндовый планировщик прекрасно отрабатывает как в серверной, так и в десктопной части. Фрюшный планировщик прекрасно отрабатывает как в серверной, так и в десктопной части. И только в б-жественном линуксе из-за "универсальности" планировщик толком не справляется ни с серверной, ни с десктопной частью.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	95. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 14:26
	> Виндовый … > Фрюшный … И тут же все вместе, включая набрасывающего на вентилятор, тут же отправились в пешее… догонять топ500
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–4 +/–
	Сообщение от zzz (??), 06-Янв-20, 14:51
	И что top500? Там серверная аль десктопная нагрузка?
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:18
	> И что top500? Там серверная аль десктопная нагрузка? Там ещё более другая, скорее пакетная.  Ну, если учонные опять не этсамое...
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 15:25
	т.е. наполовину: > как в серверной, так и в десктопной части. ты уже соврал. теперь хочешь чтобы поймали и на второй? А знаешь почему Джо неуловимый? :D
	Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

	183. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от zzz (??), 06-Янв-20, 18:19
	Алкоголь - зло.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (109), 06-Янв-20, 15:05
	> Если на MuQSS Это тот, который в idle грузит все ядра на 30-50%? Спасибо, ешьте сами.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

9. Скрыто модератором	+2 +/–
Сообщение от Аноним (9), 06-Янв-20, 10:49
Линус технично опустил Гуглоеба. Молодец товарищ Торвальдс.
Ответить | Правка | Наверх | Cообщить модератору

	14. Скрыто модератором	+/–
	Сообщение от ыфвыфв (?), 06-Янв-20, 10:56
	Неа, он просто, как всегда, отмазался, чтоб не признавать что на протяжении десяток лет они были неправы (претензии к планировщику были задолго до этого теста).
	Ответить | Правка | Наверх | Cообщить модератору

	24. Скрыто модератором	+3 +/–
	Сообщение от anonymous (??), 06-Янв-20, 11:19
	Я не поддерживаю комментарий выше по поводу "молодец, опустил", однако всё же: Можно конкретнее про претензии к планировщику и какое они имеют отношение к данному тесту?
	Ответить | Правка | Наверх | Cообщить модератору

	33. Скрыто модератором	+/–
	Сообщение от Аноним (5), 06-Янв-20, 11:44
	Я не спец, поэтому вместо ссылок на технические детали дам ссылку на неприятную историю. По ссылкам ниже - история разработки разработчика-любителя: https://www.linux.org.ru/news/linux-general/2042898 https://www.linux.org.ru/news/linux-general/4044309
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	+12 +/–
	Сообщение от Аноним (5), 06-Янв-20, 12:14
	> ссылку на неприятную историю Есть программист-любитель по имени Кон Коливас, для которого это не основная работа. Когда он писал свои первые программы на языке Си, то сообщество 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
	Ответить | Правка | Наверх | Cообщить модератору

	60. Скрыто модератором	+/–
	Сообщение от Аноним (60), 06-Янв-20, 13:05
	Сильно напоминает историю с reiser4
	Ответить | Правка | Наверх | Cообщить модератору

	96. Скрыто модератором	+2 +/–
	Сообщение от zzz (??), 06-Янв-20, 14:28
	Это не то, что напоминает - это ситуация 1:1 и даже еще более стремна. Там хотя бы покривили носы, но сделали что-то аналогичное, а в случае с reiser разработку забанили, потому что, видите ли, файлуха не должна лезть в управление томами, но при этом протащили в апстрим btrfs по настоятельной просьбе оракла.
	Ответить | Правка | Наверх | Cообщить модератору

	115. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 15:10
	Ничего общего. Reiser4 не в ядре просто потому, что единственный разработчик — Шишкин — в этом не заинтересован. Он делал прототип для демонстрации научных тезисов, разработка рабочего решения его не интересует.
	Ответить | Правка | Наверх | Cообщить модератору

	134. Скрыто модератором	+1 +/–
	Сообщение от Аноним (60), 06-Янв-20, 15:45
	До того, как Шишкин стал маинтейнером, там было много разрабов, и о включении reiser4 в ядро их упрашивали 3 года - с 2004-го по 2006-й Интересно получается: Reiser4, которая прекрасно чинит разделы - не рабочая, а Btrfs, которая не может этого сделать, оказывается, рабочая...
	Ответить | Правка | Наверх | Cообщить модератору

	148. Скрыто модератором	+/–
	Сообщение от Аноним (-), 06-Янв-20, 17:03
	Возможно, но после ухода Рейзера только Шишкин и светился. Кроме него из основных разработчтков нет.
	Ответить | Правка | Наверх | Cообщить модератору

	230. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 20:59
	Потому что с Шишкиным работать, мягко говоря, тяжко. Убедить его, что проблема на стороне его чудо-подeлки и её надо решать, гораздо сложнее, чем того же Торвальдса.
	Ответить | Правка | Наверх | Cообщить модератору

	221. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 20:29
	> Интересно получается: Reiser4, которая прекрасно чинит разделы - не рабочая, а Btrfs, которая не может этого сделать, оказывается, рабочая... Обе могут починить, а могут и не починить. С некоторой вероятностью. А лучше всего ext4 и (с недавних пор) XFS, которые не ломаются сами по себе.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	305. Скрыто модератором	+/–
	Сообщение от Евгений (??), 07-Янв-20, 05:31
	Это XFS-то не ломается сама по себе… Ох, сколько мы с ней наелись, вроде недавно в ней баги правили, может больше не будет разваливаться.
	Ответить | Правка | Наверх | Cообщить модератору

	185. Скрыто модератором	+2 +/–
	Сообщение от zzz (??), 06-Янв-20, 18:29
	Он-то как раз очень заинтересован в том, чтобы протолкнуть проект в ядро и набрать проекту популярности и разработчиков, но после того, как он несколько раз обращался в core team и его столько же раз послали, он забил на дуболомов и пилит reiserfs в сторонке. Человек подходит к вопросу с академической точки зрения, а не как это обычно в ляликсе "тяп-ляп - и в продакшн, проблемы будем решать потом". И когда такое кощунство видят ляликс-разрабы, они говорят "это прототип". Потому что матан - для лохов, а крутые перцы знают лучший рецепт - надо купить комп мощнее.
	Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

	222. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 20:33
	> Он-то как раз очень заинтересован в том, чтобы протолкнуть проект в ядро и набрать проекту популярности и разработчиков В сотрудничестве он не очень заинтересован. Тем более — с программистами, а не учёными. > но после того, как он несколько раз обращался в core team и его столько же раз послали > Человек подходит к вопросу с академической точки зрения Именно из-за его "академической точки зрения": "Проблемы? Какие проблемы? УМВР. Если у вас что-то не работает, чините сами".
	Ответить | Правка | Наверх | Cообщить модератору

	223. Скрыто модератором	+1 +/–
	Сообщение от Аноним (109), 06-Янв-20, 20:39
	Шокирующие откровения от человека, который пытался помогать Шишкину: https://www.linux.org.ru/news/linux-general/15445203?cid=154... > А вообще я про то, например, что в какой-то момент мы запретили миграцию страниц для страничного кэша reiser4, потому что «ниработаит», а искать проблему и чинить её — да кому это нужно? Академичность Шишкина не может не вызывать уважения.
	Ответить | Правка | Наверх | Cообщить модератору

	314. Скрыто модератором	+/–
	Сообщение от Аноним (6), 07-Янв-20, 08:35
	Спасибо, интересно, как изменилось мнение. Возможно, мы даже увидим весьма интересную Reiser 6, когда intelfx залечит набитые шишки, переосмыслит детали и ради шутки назовёт так свою ФС.
	Ответить | Правка | Наверх | Cообщить модератору

	293. Скрыто модератором	+1 +/–
	Сообщение от zzz (??), 07-Янв-20, 01:15
	Наоборот, он был заинтересован в том, чтобы протолкнуть файлуху в ядро, но столкнулся с людьми, которые при слове "алгоритм" делают круглые глаза и смотрят непонимающим взглядом, а решения принимают на основании не нужности или полезности, а на основании приближенности к телу решателей. Причем, reiser зарубили даже не из-за проблем (которых у тех же BtrFS/XFS ничуть не меньше), а потому что нельзя файлухе лезть в управление томами, бо есть LVM. Когда впиливали BtrFS - глазки на собственные правила (непонятно только кем сформулированные) закрыли, а как поступило предложение впилить reiser - все вдруг сразу стали коре тимо облико морале.
	Ответить | Правка | К родителю #222 | Наверх | Cообщить модератору

	233. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 21:07
	> Сильно напоминает историю с reiser4 Ага. И Шишкин, и Коливас имеют некоторые проблемы социального плана, мешающие им полноценно участвовать в разработке в составе крупного коллектива. Вот из-за этого "человеческого фактора" мы никогда не увидим я ядре ни BFS, ни Reiser4. Только не надо выставлять их жертвами. Жертвы — скорее те, кому приходится с ними работать.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	141. Скрыто модератором	+1 +/–
	Сообщение от runoverheads (ok), 06-Янв-20, 16:26
	одна лирика, ни одной ссылки на тест. если bfq так жёг, то чего его автор его закопал? а, так там не было масштабируемости на  больших системах, регресс. то то злые мейнтейнеры не хотели его в апстрим
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	158. Скрыто модератором	+1 +/–
	Сообщение от Аноним (158), 06-Янв-20, 17:13
	Да хлам он был. Даже я на чисто хомячковых задачах типа скопировать файл 1гб с ссд на хдд ловил полный лок гуя на минуту (видимо это именно то что называют 12309 судя по симптомам), причём любыми другими планировщиками чего угодно повторить не удавалось. Поэтому надо гнать ссаными тряпками, а не иделизировать дилетантов.
	Ответить | Правка | Наверх | Cообщить модератору

	159. Скрыто модератором	+1 +/–
	Сообщение от Аноним (158), 06-Янв-20, 17:17
	Хотя у меня тоже был эффект плацебо в стиле "вроде как отзывчевей переключение стало". Когда столкнулся с проблемами как-то попустило, в конце концов лучше разбросать nice приоритеты по процессам и под нагрузкой всё ок с отзывчивостью и так.
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	197. Скрыто модератором	+/–
	Сообщение от drTrue (?), 06-Янв-20, 19:04
	Коливас не программист, а анестазиолог. Вот и подросла школота которая не знает истории. По сути, Торвальдс в очередной раз облажался. Нельзя сделать щедулер который будет вов сех сценариях самым лучшим. Для дестопа нужен один тип щедулера с низкими задержками, для сервера другой где главное пропускная способность. Если аппликуха в один момент времени сильно нагружает диски, а в следующее мнгновение нагружает проц на 100% на миллисекунду то шаттный щедулер Linux не сможет подобрать правильный план выполнения поскольку он подбарет его на основе прошлой статистике поведение, а это поведение будет говорить что это приложение нагружает диски, а не проц.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	198. Скрыто модератором	+1 +/–
	Сообщение от drTrue (?), 06-Янв-20, 19:08
	Что касается bfq, то это было просто эксплутирование частоты перектлючений, если в штатном ядре оно плавает от 300 до 1000 переключений в секунду, то Коливас поднял до 10000 fix. Надо ли говорить, что это полная херня?
	Ответить | Правка | Наверх | Cообщить модератору

	215. Скрыто модератором	+/–
	Сообщение от Аноним (215), 06-Янв-20, 20:08
	Есть подобные истории из *BSD систем?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	227. Скрыто модератором	+3 +/–
	Сообщение от анонн (ok), 06-Янв-20, 20:54
	> Есть подобные истории из *BSD систем? "Не беда, что своя корова сдохла! Плохо, что соседская жива!" (с) народный аноним
	Ответить | Правка | Наверх | Cообщить модератору

	250. Скрыто модератором	+/–
	Сообщение от Аноним (215), 06-Янв-20, 22:47
	Я не с целью высмеивания, а правда интересно, для сравнения.
	Ответить | Правка | Наверх | Cообщить модератору

	228. Скрыто модератором	–3 +/–
	Сообщение от Аноним (109), 06-Янв-20, 20:57
	> Есть подобные истории из *BSD систем? Тео де Раадт со своим пиаром убер-безопасного рeшета затмевает всю эту мышиную возню =)
	Ответить | Правка | К родителю #215 | Наверх | Cообщить модератору

	232. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 21:02
	> Всё закончилось тем, что Инго Молнар написал планировщик CFS. Это был 'fair scheduling' планировщик - такой же, как -ck2. Приятно, что Инго не стал замалчивать вклад Коливаса, а поблагодарил его за то, что он его убедил в полезности 'fair scheduling'. > Коливас заявил, что CFS повторяет его планировщик, просто написан полностью "с нуля" и без оглядки на его код. Так было некрасиво поступать. И тем не менее, теперь а апстриме есть 'fair scheduling' планировщик, а значит, Коливас больше не нужен. И он принял решение уйти из разработки ядра. Если верить анонимам, утверждающим, что 12309 внесён именно CFS, получается, "благодарить" за этот баг нужно не сколько Молнара, сколько Коливаса?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	48. Скрыто модератором	+2 +/–
	Сообщение от Ordu (ok), 06-Янв-20, 12:19
	Ппц. Одна ссылка ведёт на страницу, где написано "AdBlock detected, а ну отключай его". Вторая в конечном итоге уводит на страницу, где требуется регистрация. Действительно, неприятная история. Какой-то анально-огороженный разработчик любитель.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	52. Скрыто модератором	+/–
	Сообщение от Аноним (5), 06-Янв-20, 12:27
	Это ссылки 07 и 09 годов. Арзив интернета в помощь
	Ответить | Правка | Наверх | Cообщить модератору

	70. Скрыто модератором	+1 +/–
	Сообщение от Ordu (ok), 06-Янв-20, 13:44
	А, вот почему ссылки исходно ведут на lor. Понятно. Лор как замена букмаркам браузера -- оригинально.
	Ответить | Правка | Наверх | Cообщить модератору

	121. Скрыто модератором	–3 +/–
	Сообщение от Аноним (109), 06-Янв-20, 15:15
	> Это ссылки 07 и 09 годов. Арзив интернета в помощь Офигенно, учитывая, что текущий планировщик в проде где-то с 2010 года.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	92. Скрыто модератором	+/–
	Сообщение от Аноним (94), 06-Янв-20, 14:22
	> 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, во второй чья-то жежешечка, для просмотра которой надо иметь учётку в ЖЖ, потому что просмотр только залогиненным лжеюзерам.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	118. Скрыто модератором	+/–
	Сообщение от Аноним (109), 06-Янв-20, 15:13
	А ты думал? Претензии к CFS есть, просто они секретные. Лучше не показывать их технически грамотным людям. Вот один чувак выкатил претензии к CFS в паблик — и его сразу уделал некто Торвальдс.
	Ответить | Правка | Наверх | Cообщить модератору

	139. Скрыто модератором	+/–
	Сообщение от Аноним (140), 06-Янв-20, 16:24
	> он просто, как всегда, отмазался, чтоб не признавать что на протяжении десяток лет они были неправы таки да - 12309 всё ещё случается.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	199. Скрыто модератором	+/–
	Сообщение от drTrue (?), 06-Янв-20, 19:10
	Очень сильно подтверждаю.
	Ответить | Правка | Наверх | Cообщить модератору

	79. Скрыто модератором	+3 +/–
	Сообщение от Аноним (79), 06-Янв-20, 13:57
	Линус сказал что так универсальнее. И заодно что так работает. Но не сказал что в конкретной задаче так лучше.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

11. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от Аноним (11), 06-Янв-20, 10:52
вантузный игродел решил попрграмировать под линукс и публично опозорился
Ответить | Правка | Наверх | Cообщить модератору

12. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–6 +/–
Сообщение от Аноним (11), 06-Янв-20, 10:54
> Автор теста попытался возразить Линусу ахахаха, спорить с родителем самой linux-системы лучше бы он этого не делал
Ответить | Правка | Наверх | Cообщить модератору

	15. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (5), 06-Янв-20, 10:59
	Автором планировщика для ядра Linux (что самого первого O(1), что второго, CFS) был Инго Молнар, Первый планировщик был хороший, но не идеальный, второй планировщик был ещё хуже. И когда пользователи стали жаловаться на баг 12309, вызванный переходом на CFS в ядре 2.6.23, Линус заявил, что это "совокупность багов, которые действуют в сумме, и эти баги трудно выловить по-одному и устранить". На самом деле, в более ранних версиях ядра (например 2.6.16) бага 12309 не было вообще, а его появление как-то чудесно совпало с появлением нового планировщика. Альтернативные планировщики в ядро не принимались. Тоже озвучили какую-то благоприятную причину, а истинную, стыдную, не озвучили
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (6), 06-Янв-20, 11:04
	Другое дело, оффтопик. Вызвал timeBeginPeriod() и всё стало плавно. Правда, в документации к функции написаны странные вещи. :)
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+7 +/–
	Сообщение от llol (?), 06-Янв-20, 11:08
	> На самом деле, в более ранних > версиях ядра (например 2.6.16) > бага 12309 не было вообще, а его > появление как-то чудесно совпало с > появлением нового планировщика И только разработчики с 10+ лет стажа сейчас тяжело вздохнули ибо знают, что ситуация, когда исправляешь один баг, и тут же всплывает пяток других, которые не были видны из-за первого бага, случаются очень часто.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	40. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 12:01
	> И только разработчики с 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 лет назад, что сейчас путают их между собой одни и те же "школьники"
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (5), 06-Янв-20, 12:35
	https://www.linux.org.ru/news/linux-general/2042898?cid=2045250
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 11:37
	> И когда пользователи стали жаловаться на баг 12309 ........ есть планировщик задач, а есть планировщик ввода-вывода. во-о-о-т... наводящий вопрос - как ты думаешь о каком из них лет 10 назад спорили дяди пока ты прогуливался школу?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	306. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (306), 07-Янв-20, 06:04
	баг 12309 вызван проблемами в чипсете intel вышедшем в то время, на amd как вы можете знать этот баг не воспроизводился.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	51. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+12 +/–
	Сообщение от Ordu (ok), 06-Янв-20, 12:26
	> ахахаха, спорить с родителем самой linux-системы > лучше бы он этого не делал Почему же лучше? Человек, в результате, получил обратную связь от Торвальдса. Если он не прекратит свои изыскания, но учтёт результаты беседы с Торвальдсом и продолжит исследования ещё месяца два, он будет понимать в применении спинлоков в играх столько, сколько мало кто понимает. Причём, при желании, у него есть опция написать более вдумчивую статью, сравнивающую спинлоки и мьютексы, и продолжить беседу с Торвальдсом. Вероятно, узнав ещё что-нибудь, из не лежащего на поверхности.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	59. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–3 +/–
	Сообщение от псевдонимус (?), 06-Янв-20, 13:00
	А что, спорить с ним нельзя? Можешьне отвечать, я уже понял что ты сектант.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	80. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от Аноним (79), 06-Янв-20, 13:59
	Нет. Не потому что Линус прав, а потому что спорить с ним нельзя. О том и новость.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:23
	> Нет. Не потому что Линус прав, а потому что спорить с ним нельзя. > О том и новость. Ещё один чукча-писатель. Новость о том, что блокировки -- это сложно.  И с кондачка начинать негоже.  Сперва -- тропарик :) (в данном случае изучение уже наработанного и осознание предметной области)
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (156), 06-Янв-20, 17:11
	Еще можно придумать заголовок что у Линуса новая должность капитан очевидность. Его основной довод что так уже работает и так универсальные ну и он в этом прав. А чувак который на него наезжает говорит что может быть лучше как минимум в некоторых случаях что какбэ тоже уже тянет на помощника капитана.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (109), 06-Янв-20, 15:19
	> А что, спорить с ним нельзя? Не стоит спорить с людьми, которые умнее и грамотнее тебя в предметной области.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	127. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:24
	>> А что, спорить с ним нельзя? > Не стоит спорить с людьми, которые умнее и грамотнее тебя > в предметной области. А вот разговаривать -- стоит.  Скорее с "почему" и "зачем", по опыту.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от псевдонимус (?), 06-Янв-20, 15:50
	От того что Линус грамотнее меня в своей предметной области игрушка шустрее работать не станет.как нет т не будет массового десктопа под ним. Одни фрикции устаревшего ещё при рождении ядра.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	169. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (157), 06-Янв-20, 17:36
	В общем виде: Игроделы заточились под вынь. Тупой порт на другие платформы дает тупой результат. Какие претензии ко второй платформе? Претензии к игроделам
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–3 +/–
	Сообщение от псевдонимус (?), 06-Янв-20, 17:55
	Претензия ко второй платформе проста:она пытается уметь все. А когда указывт на косяки фанатики говорят что это фичи, как например в темах  о линуксовом управлении памятью Формально да, Линус в этом споре прав.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (306), 07-Янв-20, 06:06
	А ненадо всё валить в кучу, планировшик и vm это разные вещи.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от псевдонимус (?), 07-Янв-20, 20:27
	> А ненадо всё валить в кучу, планировшик и vm это разные вещи. Вот и не надо мешать задачи сервака, суперкомпа и десктопа, прикрываясь фиговым листом универсальности.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 20:44
	Вторая платформа если уж решила быть комбайном могла бы подумать про качество работы в некоторых задачах. Или признать что не шмогла.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	315. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 07-Янв-20, 08:47
	> В общем виде: > Игроделы заточились под вынь. В таком случае они бы использовали критические секции, а не велосипед. > Тупой порт на другие платформы дает тупой результат. > Какие претензии ко второй платформе? > Претензии к игроделам Когда они игры играли, а не писали, timeBeginPeriod() по документации не имела отношения к планировщику и считалась хаком.
	Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

	254. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (254), 06-Янв-20, 23:01
	Ну Windows спасет только мощное железо А даже на старом хламе вполне норм линукс работает А игры на Ютубе вполне проходятся
	Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

	138. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (94), 06-Янв-20, 16:16
	А как тогда вытащить из них то, чем они умнее и грамотнее? Иного приходится привселюдно неучем обозвать, чтобы он раскрылся и выдал что-то по существу. Понимаю, что это, в общем-то, разновидность троллинга, не самое лучшее дело для кармы, но приходится иногда и к таким методам прибегать.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	270. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 23:45
	>А как тогда вытащить из них то, чем они умнее и грамотнее? Методика паразита. Учиться не пробовал? Помогает.
	Ответить | Правка | Наверх | Cообщить модератору

19. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+6 +/–
Сообщение от Аноним (19), 06-Янв-20, 11:08
Кон Коливас смотрит на эту дискуссию, как на битву нанайских мальчиков
Ответить | Правка | Наверх | Cообщить модератору

	86. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от Аноним (86), 06-Янв-20, 14:11
	http://ck-hack.blogspot.com/2020/01/happy-new-decade.html
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 21:16
	MuQSS support cgroups, but not all the cgroup features (e.g. CPU limiting will not work). Кону Коливасу пофек.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

26. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
Сообщение от Аноним (26), 06-Янв-20, 11:21
Забавно читать про "более простые планировщики". Знания внутренностей ядра 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++, ...).
Ответить | Правка | Наверх | Cообщить модератору

	34. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (8), 06-Янв-20, 11:45
	Где почитать более свежие исходники ядра Windows? Дайте адрес на GitHub
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 06-Янв-20, 11:54
	Нигде. Проприетарщина. Тут Linux впереди планеты всей. Лишь бы работал хорошо. Исходный пост не про то, что Linux плох, а про то, что он не для тех задач и условий, для которых создавался Windows.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 12:10
	ну и нафига тогда этот спич выше про вантуз, если сабж — цитата: > … игр, создаваемых для сервиса Google Stadia, в котором игры выполняются на GPU в облачном окружении ? очевидно вантузный шедулер тут не применим
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 06-Янв-20, 13:18
	Спич про Windows к содержимому ответа Linus'а, и некоторой части коментаторов в mailing list'е и здесь. В Google Stadia - вероятно не применим. Но ведь оригинальная статья упоминает Google Stadia лишь как начальный толчок к исследованию. А часть комментаторов просто начинает кидать гнилые помидоры в сторону Windows, не разбираясь толком ни в том, ни в другом.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от ананим.orig (?), 06-Янв-20, 14:19
	про затмения на Марсе — тоже очень интересная тема. при этом они также ничего не меняют (и не добавляют) к сабжу вообще и к содержимому ответа Linus'а в частности
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Аноним (26), 06-Янв-20, 15:23
	> про затмения на Марсе — тоже очень интересная тема. Интересная наверное тема, да. > при этом они также ничего не меняют (и не добавляют) к сабжу вообще и к содержимому ответа 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-х (если не раньше), превратились в мире СПО в своеобразный постулат, который, на самом деле, устарел. Проприетарный код развивается не хуже свободного, а про это иногда забывают.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от drTrue (?), 06-Янв-20, 19:16
	M$ предоставляет исходники своей продукции включая Windows всех версий в ФСБ, иначе не смогла бы продавать на территории РФ.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	235. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (109), 06-Янв-20, 21:12
	МС предоставляет бабки, а не исходники. Кстати, > иначе не смогла бы продавать на территории РФ. Неправда. Сертификация ФСТЭК нужна только для госзакупок в организации, работающие с гостайной. Продавать системы с предустановленной ОС в обычных магазинах можно без сертификатов, сотни разных андроидов не дадут соврать.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от drTrue (?), 06-Янв-20, 22:01
	>Неправда. Сертификация ФСТЭК нужна только для госзакупок в организации, работающие с гостайной. Нет, для закупок винды в госучреждения код винды должен был быть предоставлен ФСБ для изучения и он был предоставлен. Гугол в помощь. Что забавно, этот код ещё в бородатые 90-е (на рубеже 99-2000 если не ошибась или на пару лет позже) везли из аэропорта (куда код прилетел из США) на инкасаторском броневике. Даже в новостях показывали репортаж.
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от anonymous (??), 07-Янв-20, 11:05
	И гугл как раз скажет, что сертификаты нужны для аттестации, а аттестовать нужно лишь определённые системы. Либо обрабатывающие тонны ПДн, либо работающие с гос. тайной и т.п. Более того, обычно достаточно ФСТЭК-овских сертификатов.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от nich (ok), 07-Янв-20, 09:03
	Windows Internals 7th edition
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	42. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (42), 06-Янв-20, 12:04
	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. В линуксе вот этот момент гораздо правильней реализован
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	61. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от Аноним (26), 06-Янв-20, 13:10
	Угу. Процитирую эту статью: > 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 тоже неплох, да ещё и развивается.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (6), 06-Янв-20, 13:40
	> Угу. Процитирую эту статью: >> 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" условие, но я не делал утверждения "никогда не происходит".)
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 06-Янв-20, 14:49
	Люблю когда по делу переписка. По первому куску кода 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 (ноды, а не конкретного ядра).
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 16:06
	> Люблю когда по делу переписка. Э, нет, дружище, я тут не весть какой помощник. Мне это было интересно, когда сорцы 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 (ноды, а не конкретного ядра). А что, сейчас такие вещи нигде толком не обсуждаются?
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 17:39
	> исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил. Вероятнее всего. Вопрос - понимает ли автор, что стоит за этим словом? > на каком IRQL выполняется спящий поток? Да, занятный, но я бы на него ответил контрвопросом "в какой-то конкретный момент или в целом?". Но вообще это наверное для проверки на вшивость разработчика драйверов, нежели ради реальных знаний. > Понятно, что должно быть перераспределение. Да, но оно не* результат перераспределения как такового, а, например, результат поиска работы того же idle thread. Но Ideal процессор то не менялся. > Представляю, какие были ощущения у online-solutions.ru > когда MS выкатило очередной подарок. Кто это? Никогда о них не слышал. Вот у настоящих производителей антивирусных пакетов я думаю неплохо так горит от каждого обновления Windows, ибо их любимый хардкод и хаки начинают рассыпаться (и вводить в BSoD/GSoD или приводить к ошибке обновления до новой версии). > А что, сейчас такие вещи нигде толком не обсуждаются? Есть любители поковырять ядро, но обычно знания остаются у расковырявшего. Увы.
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 19:19
	>> исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил. > Вероятнее всего. Вопрос - понимает ли автор, что стоит за этим словом? Он относит busy к ядру процессора, которое в принципе не может быть idle (но может находиться в HALT state). >> на каком IRQL выполняется спящий поток? > Да, занятный, но я бы на него ответил контрвопросом "в какой-то конкретный > момент или в целом?". Но вообще это наверное для проверки на > вшивость разработчика драйверов, нежели ради реальных знаний. Это к пониманию работы механизма переключения контекстов выполнения (а это только планировщик, но и диспетчер). >> Понятно, что должно быть перераспределение. > Да, но оно не* результат перераспределения как такового, а, например, результат поиска > работы того же idle thread. Но Ideal процессор то не менялся. >> Представляю, какие были ощущения у online-solutions.ru >> когда MS выкатило очередной подарок. > Кто это? Никогда о них не слышал. Вот у настоящих производителей антивирусных > пакетов я думаю неплохо так горит от каждого обновления Windows, ибо > их любимый хардкод и хаки начинают рассыпаться (и вводить в BSoD/GSoD > или приводить к ошибке обновления до новой версии). Споров организовал в своё время. Их OSAM тогда сразу же обогнал AutoRuns. Основной продукт был с серьёзным замахом, но так и не выпустили, поскольку MS кислород перекрыли.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 06-Янв-20, 17:46
	> Реверс Windows 10 - совсем иные ощущения. Ну и что там внутри, мой анонимный брат?
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	176. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 17:54
	Гора неочевидного кода, твой анонимный брат. Неочевидного - потому что ты не знаешь настоящей причины, зачем он там. А ведь он нужен. Ах да, это же прямо как исходники Linux, с патчсетами от крупных компаний-производителей процессоров, спеки то всё равно только они имеют. Конец минутки неудачной иронии.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 06-Янв-20, 19:54
	> Гора неочевидного кода, твой анонимный брат. Неочевидного - потому что ты не > знаешь настоящей причины, зачем он там. А ведь он нужен. Ох уж эти индусы… > Ах да, это же прямо как исходники Linux, с патчсетами от крупных > компаний-производителей процессоров, спеки то всё равно только они имеют. Конец минутки > неудачной иронии. «Это свобода!» — говорили они нам лет около двадцати назад.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 06-Янв-20, 14:00
	Хочу уточнить: твои придирки, как я понял, относятся не к фактической части, а к теоретической? То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро, тебя не устраивает то, как эти перекидывания объясняются, так?
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	129. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 15:28
	> То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро, Я утверждаю, что их нет (до введения Cache Aware Scheduling пару недель назад). > тебя не устраивает то, как эти перекидывания объясняются, так? Меня не устраивают неверные утверждения про то что современный планировщик Windows не в курсе про SMT/HT/NUMA/архитектуру Ryzen, или что он имеет всего одну глобальную очередь потоков на выполнение  (или даже что он имеет одну локальную для ядра очередь потоков). А следовательно - про его простоту.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 06-Янв-20, 17:03
	>> То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро, > Я утверждаю, что их нет (до введения Cache Aware Scheduling пару недель > назад). В смысле, они были до введения Cache Aware Scheduling пару недель назад, я правильно понял? Статья от ноября 2019 года. То есть она всё говорит правильно.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 17:59
	Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений, вывести противоположное утверждение? НЕ было. Так ясно? В статье лажа не по этой причине, а из-за следующих двух параграфов с голословными заявлениями (и противоречащим реалиям, если посмотреть код или почитать авторитетные источники вроде Windows Internals), ставящих под сомнение всё их экспертное мнение.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 18:55
	Где это такое видано чтобы оба сабжевых оратора были не правы? Либо черное либо белое. Либо один прав, либо другой, третьего не дано. Таков путь.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 06-Янв-20, 19:23
	> Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений, > вывести противоположное утверждение? Как можно писать, что я читаю одно твоё сообщение за другим, и до сих пор продолжаю уточнять, что именно ты имеешь в виду? > НЕ было. Так ясно? Нет, не ясно. Чего именно не было? Те графики в статье показывающие как поток выполенения перепрыгивает с ядра на ядро -- туфта нарисованная в фотошопе? > В статье лажа не по этой причине, "Не по этой" -- это не по какой? Я простите не телепат, чтобы угадывать, на что именно ты ссылаешься всеми этими своими местоимениями.
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

	214. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 19:56
	> они были до введения 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 тоже предпочитает оставлять потоки на последнем ядре выполнения. Но может и сменить.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Ordu (ok), 06-Янв-20, 21:12
	>> они были до введения 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 и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 07-Янв-20, 09:18
	> В перекидывании потока: за ним ведь приходится тянуть все кеши. Ну, нет. Представим ситуацию. Поток 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. Зачем я должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? Смысл пересказывать содержимое книги?
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Ordu (ok), 07-Янв-20, 12:09
	>> В перекидывании потока: за ним ведь приходится тянуть все кеши. > Ну, нет. Представим ситуацию. Поток 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". Второй важный навык -- это умение объяснять и отвечать на вопросы. Ты здесь и сейчас продемонстрировал, что ни один из этих навыков тебе недоступен. Я чёрть-его-знает-сколько времени выуживал из тебя ответы на простые вопросы, получая ненужные мне ответы на вопросы, которых я не задавал. Как ты вообще работаешь консультантом при этом? В качество профориентационного совета: тебе лучше податься в маркетинг или в политику -- там как раз очень полезно умение уходить от прямых вопросов, создавая при этом впечатление открытости и готовности развёрнуто отвечать на любые вопросы. > Зачем я > должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, > если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? > Смысл пересказывать содержимое книги? Мне не нужно содержимое книги, мне хочется знать короткое объяснение простому феномену: почему венда жонглирует потоком между свободными ядрами, хотя оно могло бы оставить его крутится на одном ядре.
	Ответить | Правка | Наверх | Cообщить модератору

	330. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 07-Янв-20, 12:55
	> С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают? "С какого полового члена" взято что они простаивают? Из сценария из статьи, точнее из графика из неё, из которого не понятно даже это нагрузка от одного процесса или от всей системы? Я про свой сценарий, который может совпадать со сценарием из статьи, когда помимо одного однопоточного приложения есть неравномерная нагрузка и на остальные ядра (от других процессов), но не 100%. > Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем? Конечно читал, ибо реагирую. > В моём первом сообщении был вопрос: "твои придирки, как я понял, относятся не к фактической части, а к теоретической?". Фактическая часть -- это как раз те самые графики, которые демонстрируют как имея несколько свободных ядер, венда перекидывает поток жрущий 100% времени одного ядра между ядрами. Теоретическая часть -- это объяснение происходящего с отсылками к устройству планировщика задач венды. Если так поставить, да. Мои "придирки", "относятся не к фактической части, а к теоретической". Ну и спасибо за полезные советы, я ими непременно воспользуюсь по назначению.
	Ответить | Правка | Наверх | Cообщить модератору

	335. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Ordu (ok), 07-Янв-20, 13:18
	>> С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают? > "С какого полового члена" взято что они простаивают? Из сценария из статьи, > точнее из графика из неё, из которого не понятно даже это > нагрузка от одного процесса или от всей системы? Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра. > Я про свой > сценарий, который может совпадать со сценарием из статьи, Да кому он нужен твой сценарий, если в статье идёт обсуждение вполне конкретного сценария? И вообще, если ты меняешь сценарий, ты хоть предупреждай собеседников. Я бы даже не парился общаться с тобой, если бы с самого начала знал, что ты на своей волне сам с собой разговариваешь. >> Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем? > Конечно читал, ибо реагирую. https://www.physics-astronomy.org/2019/04/marijuana-contains...
	Ответить | Правка | К родителю #330 | Наверх | Cообщить модератору

	345. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 07-Янв-20, 15:26
	> Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра. В этой статье нет даже объяснения, что этот график изображает. "Single-threaded workload bouncing between cores". Это график той самой нагрузки (только от неё)? Или нагрузки на ядра (в целом, с учётом остальных потоков других процессов)? В статье нет даже упоминания этого графика, хотя контекстуально он вероятно релевантен. Но он просто "есть", в отрыве от статьи. Я привожу пример сценария, в котором график будет корректным, соответствовать контексту, но означать не "тупость" планировщика, как это указано в статье. Да и помимо этого графика в статье есть ошибочные утверждения (что легко проверяется с помощью качественной книги или IDA Pro/Ghidra/...). > [14.335] Да кому он нужен твой сценарий, если в статье идёт обсуждение вполне конкретного сценария? > [13.330] сценарий, который может совпадать со сценарием из статьи :/ > [14.335] И вообще, если ты меняешь сценарий, ты хоть предупреждай собеседников. > [11.318] Представим ситуацию. :/ Спасибо за ссылку, могу вкинуть ещё парочку интересных.
	Ответить | Правка | К родителю #335 | Наверх | Cообщить модератору

	354. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 07-Янв-20, 20:04
	>> Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра. > В этой статье нет даже объяснения, что этот график изображает. "Single-threaded workload > bouncing between cores". Это график той самой нагрузки (только от неё)? > Или нагрузки на ядра (в целом, с учётом остальных потоков других > процессов)? В статье нет даже упоминания этого графика, хотя контекстуально он > вероятно релевантен. Но он просто "есть", в отрыве от статьи. У меня не возникло проблем понять этот график. Автор сделал открыл какую-то тулзу, которая рисует график загрузки ядер, прибил все процессы, которые давали заметную нагрузку, после чего запустил какую-то однопоточную нагрузку -- может быть это был while(1) i++; скомпилированный с -O0, может быть это было какое-то приложение, которое считало гуглоплексы знаков пи, может это было что-то ещё. И он получил графики, которые мы видим. Я не вижу способа, как он здесь мог накосячить -- запустить что-то, что блокировалось на вводе-выводе? Но график был бы иной, он бы не достиг 100% загрузки процессора. Может у него был какой-то другой процесс, который съедал, допустим, 20% времени процессора, а его процесс кушал 80%? Или его нагрузка была многопоточной? Но в этом случае ему сильно повезло, что эти процессы так чётко отъедали процессорное время так, чтобы в сумме получалось бы 100%, и ещё ему повезло, что они всегда по двум ядрам раскидывались и не занимали остальные. Короче, я не вижу, как он мог сделать что-то не то. Может я неправильно понимаю график, и эти кривые отражают что-то иное, не загрузку хардварных тредов? Но что, например? Я не вижу, что это может быть ещё. Я выше дважды сказал "я не вижу", если насчёт хотя бы одного "я не вижу", ты можешь сказать "а я вижу" и объяснишь, что именно ты видишь, то я соглашусь с тобой, что тут серьёзный косяк со стороны автора. Если ты не можешь предположить ничего, значит косяка тут нет: автора и его картинку можно понять единственным образом и дополнительных пояснений не требуется. > Я привожу пример сценария, в котором график будет корректным, соответствовать контексту, > но означать не "тупость" планировщика, как это указано в статье. Ты не приводишь сценария, который бы соответствовал графику. Если бы на систему была сколь-нибудь существенная нагрузка кроме тех вычислений знаков пи, то мы бы это видели. Более того, на графике мы видим пару всплесков фоновой активности, когда вдруг другие ядра ненадолго просыпаются и начинают что-то делать. > Спасибо за ссылку, могу вкинуть ещё парочку интересных. Вообще эта ссылка была ответом на утверждение, что из того, что ты реагируешь, всенепременно вытекает, что ты читал статью. Не вытекает. Эти реакция и чтение не обязательно сопутствуют друг другу.
	Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

	358. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 07-Янв-20, 21:09
	Я уже начинаю уставать от этого диалога, если честно. Я не говорю, что автор графика накосячил (вероятнее всего ошибок в графике нет, хотя к нему не хватает комментариев). Я утверждаю, что подобное поведение (перескакивание потока с ядра на ядро) легко объясняется без пинков в сторону "примитивности" планировщика. Я предоставляю очень вероятный сценарий (в сообщении 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.
	Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

	370. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 08-Янв-20, 02:06
	>  Объективно, это позволяет эффективнее использовать все ядра. Да, тогда когда занятых работой потоков больше чем ядер. Когда их меньше, получается фигня. > В статье же, по незнанию автора (статьи, ибо автор статьи и графика > может не совпадать) этот эффект истолковывается иначе (и делаются неверные выводы), > якобы ядро 2 крадёт поток A у ядра 0 только потому, > что оно освободилось (в реальности ядро 0 просто отключилось от потока > A по расписанию, и начало другую работу; если другой работы бы > не было, планировщик продлил бы т.н. Quantum Target и вернул управление > потоку A). Утверждая про некорректное истолкование, я напрямую опираюсь на чётко > описанный материал в самой авторитетной технической книге по внутренностям Windows. Ах вот оно что... Знаешь как планировщику следовало бы поступить? Ему бы следовало мониторить активность задач, и заметить, что одна задача серьёзно занята чем-то и хочет сожрать столько процессорных квантов, сколько возможно, и в то же время он должен был заметить, что суммарная производительность остальных ядер более чем в 100 раз больше, чем требуется остальным задачам, а раз так, то следует прибить гвоздями занятую задачу к тому ядру, на котором он выполняется, и шедулить остальные задачи по свободным ядрам. Именно это делает ядро linux, именно поэтому в аналогичной ситуации на линуксе, сильно занятая задача будет "захватывать" ядро на несколько секунд за раз, а не на 40 миллисекунд в среднем. Ядро windows этого не делает, что ты своими объяснениями подтверждаешь. Именно поэтому "dumb windows scheduler", и "ненужное перекидывание потоков". Обрати внимание, несмотря на техническую неграмотность, автор статьи лучше тебя ухватил суть проблемы. Это очень похоже на тот редкий случай, когда избыточная грамотность вредит. Самое интересное, что твоё более точное описание ничего не изменило в моём понимании ситуации. Ну, то есть, понятно, что крайне сложно выстроить идеальную ситуацию, когда в системе есть ровно один процесс, и всегда есть много процессов, и даже если они и спят 99.99% времени, всё же они иногда просыпаются и требуют квантов процессорного времени. Это настолько понятно, что не заслуживает даже упоминания, если по-хорошему. И способность венды держать занятый поток на одном ядре в идеальной ситуации, когда нет этих почти-всегда-спящих процессов -- совершенно бесполезная способность, потому что так не бывает. А как при этом объяснять это -- "ядро крадёт задачу" или "планировщик выделяет квант другой задаче" -- с мой точки зрения не важно совершенно: это просто разные уровни объяснений. Так же как одну и ту же программу можно написать на lisp'е или на asm'е, в каждом случае выбирая различные абстракции в предметной области, так и объяснять можно на разных уровнях и в разных абстракциях.
	Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

	374. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 08-Янв-20, 10:55
	> Да, тогда когда занятых работой потоков больше чем ядер. Это практически всегда так. На моём домашнем десктопе с 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, а отношение ядер/потоков явно не в пользу ядер).
	Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

	43. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 12:05
	> Забавно читать про "более простые планировщики". Знания внутренностей ядра Windows типичного > Linux-апологета видимо ограничивается уровнем Windows XP/слитых исходников Win2000. А что, в тех сорцах есть планировщик?))
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	62. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 13:12
	Без понятия. Если не там, то вероятно в Windows Research Kernel есть. Там и исходники посвежее должны быть (Windows XP, а не 2000).
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от segesg (?), 06-Янв-20, 12:14
	Марк, это ты? =)
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	97. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от колба (?), 06-Янв-20, 14:29
	технически у виндовс нет универсального планировщика который создан с учётом и серверов и десктопов.. они сознательно от этого отказались разделив версии системы.. и да планировщик винды заточенный под десктопы сейчас возможно даже сложнее чем любой другой..
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	108. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 15:01
	Технически, у Windows только универсальный и есть. Код Windows клиентских и серверных редакций (отвечающий за планировщик потоков) един. Есть различия в стандартных значениях констант (Quantum Reset например, у серверных редакций промежуток времени выполнения одного потока дольше в 4 раза). Есть ограничения по количеству ядер (опять, зависит от редакции, на бывшей Home редакции не получится поднять датацентр, да и Pro ограничения маловаты для этого). Но планировщик один. В некоторых случаях он лучше Linux'ового (например для домашнего ПК, или для небольших датацентров из коробки, т.е. до того как прийдёт профи Linux админ и начнёт крутить параметры sysctl).
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (146), 06-Янв-20, 16:42
	Можно что угодно говорить про преимуществах ядра винды, но если нельзя убедиться в этих достоинствах, недостатках и особенностях своими глазами — грош им цена. Не раз и не два я в своей жизни нырял в исходники как линукса, так и дарвина, чтобы расковырять баг или разобраться в поведении. А когда такие баги попадались под виндой, я глядел в глубокие стектрейсы из ядра да системных dll, разводил руками и вставлял костыль.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	152. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 17:04
	Любой код можно расковырять, нужно лишь быть достаточно любопытным (и имеющим время до deadline, если таковой имеется). И вероятнее всего окажется, что ошибка в своём коде, а не в ОС, причём в неправильном использовании API (ведь кто читает документацию?), как очень часто рассказывает Raymond Chen в блоге The Old New Thing. Но никто не спорит, если есть исходники - не надо запускать IDA/Ghidra/Cutter/radare2/WinDbg.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (231), 06-Янв-20, 20:51
	Я понятия не имею, что там в windows (не интересует вопрос), но крутить в юзерспейсе спинлоки с yield-ами на SMP - это выстрел себе в ногу, это в чистом виде UB. Такой подход уместен разве что в ОС с кооперативной многозадачностью, типа Windows 3.1.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	299. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (299), 07-Янв-20, 03:24
	Там дело еще осложняется тем, что код исполняется в виртуалке.
	Ответить | Правка | Наверх | Cообщить модератору

	392. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (231), 09-Янв-20, 02:29
	Ха, ну это вообще тогда чувак измерял громкость жужжания комара, стоя рядом с работающим самолетным двигателем.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 20:59
	> В каждой версии Windows планировщик значительно усложнялся И все меньше винды оставалось на top500. Это факт, а факт - самая упрямая вещь на свете. >Windows же нацелен на работу на домашних ПК либо на серверах до 1000 (1280 если быть точнее) ядер Винда - игровая платформа. Только. >где должны хорошо работать приложения, написанные любым программистом, на любом хипстерском ЯП (Go, JS, ...) и не очень (C, C++, ...). Игры, например. Замечательно работают. В одно ядро.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	249. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (249), 06-Янв-20, 22:42
	У нас каждый первый комментатор опеннета похоже на топ500 работает.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 22:58
	Статистику в студию...
	Ответить | Правка | Наверх | Cообщить модератору

	296. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (249), 07-Янв-20, 02:52
	На что статистику? Как мой саркастический комментарий по поводу 500 компьютеров из множества всех относится к теме? Да собственно так же как твой комм про топ500. Давай не про топ500 тогда вбросим а про космос. Там твои что х86 что линухи в пролете.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 00:21
	> Винда - игровая платформа. Только. Поражают воображение легенды и мифы опоздавших родиться мамкиных погромиздов.
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	321. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 07-Янв-20, 09:43
	> И все меньше винды оставалось на top500. Это факт, а факт - самая упрямая вещь на свете. Благодаря таким комментариям начинаешь забывать, что у Linux есть другие, более классные достижения. > Винда - игровая платформа. Только. О божечки. Как же некоторые ограниченны. Даже в магазины наверное не ходят, не видят Win2000/WinXP на каждом кассовом терминале (хотя может в default city уже все на Linux, я просто в России живу). Ну и работают наверное фрилансом, ибо в офисах (даже в IT-компаниях) Linux как-то не часто можно увидеть. > Игры, например. Замечательно работают. В одно ядро. Зацикленность на одном. Игры - похоже лимит воображения. Мышление из 2005 (когда там СТАЛКЕР: Тень Чернобыля вышла?). Все игровые движки многопоточные, как на Windows, так и на Linux. Советую почитать исходники Unreal Engine или CryEngine, если хотите мейнстримных движков. Я уже не говорю о "просто померить".
	Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

	256. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (254), 06-Янв-20, 23:06
	Js другое хипстерское убожество на Винде настолько тормознуто что линукс встроили - wsl а потом wsl2 на виртуалки переделали
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	319. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 07-Янв-20, 09:29
	Справедливости ради, node.js на Windows тормозит не из-за сетевого стэка либо планировщика, а из-за файловой подсистемы (включая, но не ограничиваясь, NTFS). А любая вещь на JS не может работать без папки node_modules с миллионом файлов внутри. Увы. А файловый стэк - да, известная боль на Windows. WSL - замечательное начинание, которое мне позволяет из Windows работать с Valgrind'ом без виртуалок, дебажить порты Win32 приложений под Linux, не париться по поводу копирования в буффер обмена (cat | clip.exe, вместо cat | xclip, что не работает, ибо какого лешего я должен помнить про необходимость -selection с параметром, который тоже надо помнить? Почему Linux для меня, десктопного юзера, так не дружелюбен?). WSL2 - увы, шаг назад с моей точки зрения.
	Ответить | Правка | Наверх | Cообщить модератору

45. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
Сообщение от segesg (?), 06-Янв-20, 12:10
Линус прав в том что спинлоки надо уметь. Скорее всего автор теста не читал https://stackoverflow.com/questions/4725676/how-does-x86-pau... и https://stackoverflow.com/questions/12894078/what-is-the-pur... а зря!
Ответить | Правка | Наверх | Cообщить модератору

	263. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–3 +/–
	Сообщение от Аноним (263), 06-Янв-20, 23:29
	Статью не читай @ сразу отвечай? Всё там правильно сделано. Опозорился тут как раз Линус, публично признав что его ОС не подходит для десктопа и что сделано хреново ради "универсальности".
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (306), 07-Янв-20, 06:09
	Да это прямо в документации написано http://man7.org/linux/man-pages/man3/pthread_spin_init.3.html в NOTE. Линус просто man процитировал.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

49. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
Сообщение от Аноним (49), 06-Янв-20, 12:20
Для игр вообще должны применяться системы без многозадачности. Или с вытесняющей многозадачность там и задержки будут меньше. А все эти гугл стадии на веселеньком универсальном железе это прямой путь к лагам. Только для казуальщины может быть подойдут.
Ответить | Правка | Наверх | Cообщить модератору

64. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
Сообщение от Forth (ok), 06-Янв-20, 13:17
Линус же указал страждущему правильный путь :) Есть же планировщик реального времени FIFO. В нем вытеснения нет. Каждый spin-lock гарантировано дождется освобождения без прерывания. Если spin-lock с таким же номером ядра/процессора как и твой, можно смело делать sched_yield, все равно другой тред занял этот лок на твоем же ядре. (И cpu affinity не забыть) :)
Ответить | Правка | Наверх | Cообщить модератору

	98. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от колба (?), 06-Янв-20, 14:32
	я в целом изначально удивлён что на стадии не риалтайм использовали, но думаю инженеры гугла по разному поиграются и в итоге найдут специфичное для своей системы решение которое будет лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от paulus (ok), 07-Янв-20, 03:20
	Да пусть сначала гуглоиндусы все свои сервисы и приложения нормально сделают, а потом что-то вякают на другие системы. Не говорю, что в линуксе все просто супер на десктопе... НО гуглоидусы бы лучше помалкивали. #imho
	Ответить | Правка | Наверх | Cообщить модератору

	371. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (371), 08-Янв-20, 06:30
	Думаю Стадию закроют в 2021-2022 году. :-)
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

66. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
Сообщение от Аноним (66), 06-Янв-20, 13:19
>> Линус возразил, что планировщик Linux является универсальным, оттачивался десятилетиями и оптимизирован не только для рабочего стола и игр, но и для других видов нагрузки, например, для серверных систем, поэтому учитывает множество нюансов при планировании выполнения задач. Занятно, Линус обвиняет другого разработчика в некомпетентности, при этом сам подтверждая его слова, что планировщик линукса говно? Разраб написал, что планировщик крайне плох для десктопов, а их величество оправдывает это "универсальностью". Не уж то Линус так против продвижения линукса на другие системы? Почему нельзя сделать 2 разных планировщика, которые будут работать лучше в определённых ситуациях, и дать возможность выбора пользователю одного из них? Или "опенсорс - пишите сами для себя"? По его мнению что, строители и ювелиры работают стандартизованными молотками? "Понапридумывали кувалд -они ни кому не нужны"?
Ответить | Правка | Наверх | Cообщить модератору

	72. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (79), 06-Янв-20, 13:45
	Предположу что делать кастомную систему под каждую задачу ДОРАГА. Есть же системы реального времени для своих задач и прочие узкоспециализированные ос и стоят они дорага!!!!
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (137), 06-Янв-20, 16:15
	Ну, стоит заметить, что север и десктоп очень разные и широко распространённые задачи. Совсем неплохо было бы иметь 2 планировщика. Та же jvm имеет 2 jit компилятора для сервера и клиента, бо юз кейсы очень разные и потенциальный выйгрыш того чтобы заморочится.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 17:07
	Погоди-ка под десктоп линукс вроде особо и не заточен судя по перекосу в распространении. Или Суперкомпьютеры так и ждут чтобы потормозить?
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (137), 06-Янв-20, 18:08
	Не десктоп а клиент. И да, на линуксе десятки миллионов если не больше клиентов , в т.ч. десктопы, планшеты, смартфоны, телевизоры, в общем всё что имеет GUI.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (158), 06-Янв-20, 20:24
	>в т.ч. в таком случае это уже десятки миллиардов, не?
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (304), 07-Янв-20, 04:46
	> jvm имеет 2 jit компилятора для сервера и клиента Разве? AFAIK, компилятор один, отличаются только дефолтные настройки типа продолжительности сбора статистики перед компиляцией и вероятности перехода от интерпретатора сразу к C2.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	271. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (11), 06-Янв-20, 23:46
	> при этом сам подтверждая его слова, что планировщик линукса говно? ага ты его раскусил удали линукс и пользуйся windows 10, только не забуть проапгрейдится на мощный компо чтоб windows было не говном и не лагало
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	309. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (306), 07-Янв-20, 06:10
	Если тебе что-то не подходит то это не значит что оно гавно.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

67. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
Сообщение от Аноним (66), 06-Янв-20, 13:29
>> Так как измерение производительности выполняется на основании абсолютных значений таймера, определённые в тестах задержки охватывают не только задержки в обработчике блокировки, но и код, который был выполнен в другом контексте, т.е. измеряют не только то, что пытался измерить автор теста, но и "шум" от других вычислений в системе. Это финиш. Как не странно, в конечном счёте важно общее время выполнения - отзывчивость системы. И толку 0 от того, что "чистое время всего 1 мкс", если итоговая задержка 1 с. Потому что ответ пришёл через 1 с, а не 1 мкс. Именно это общее время и есть самый главный показатель, и в нём отражены все накладные расходы в системе. В том числе и то, что в момент обработки планировщик вытеснил наш поток и отдал управление другим задачам. Вместо того, чтобы версии выпускать, лучше бы развитием системы занялся. Универсальная система, которая одинаково фигово работает как на десктопе, так и на серверах, такое себе решение. Вместо тешения своего чсв, лучше бы добавил возможность оптимизации под задачи пользователей. Та же винда с незапамятных времён имеет возможность оптимизации, банальным переключением флажка в формочке, без перекомпиляций. А эти даже с исходниками не могут до сих пор реализовать.
Ответить | Правка | Наверх | Cообщить модератору

	71. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от Аноним (6), 06-Янв-20, 13:44
	Наберите в поисковике "система реального времени", ознакомьтесь с определением -- есть куда двигаться дальше. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (79), 06-Янв-20, 13:49
	Можно и линукс с реалтайм ядром запускать, но есть минусы -   Приложения реального времени выполняются в пространстве ядра, следовательно, они могут переписать часть памяти ядра и сломать систему -   Взаимодействие между RT-подсистемой и Linux не может быть реального времени -   Ядро Linux выполняется в бэкграунде, следовательно, задачи Linux могут испытывать большие задержки -   Невозможно использовать драйверы Linux в задачах реального времени, следовательно, разработчики приложений реального времени вынуждены переписывать драйверы устройств поверх RT-подсистемы Результат конечно может и быстрый, но минусы какбэ намекают.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 14:09
	Правомерны ли исходные претензии к не реалтайм системе?
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+3 +/–
	Сообщение от Forth (ok), 06-Янв-20, 14:45
	Это если нужен hard-realtime. Для soft-realtime хватит и обычного preempt_rt. Я не знаю как на x86, на cortex-a нас задержки устраивают. С sched_fifo в нашем проекте я пока не видел провалов планировщика, когда задача получила управление позже, чем ожидается.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	241. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–3 +/–
	Сообщение от Аноним (19), 06-Янв-20, 21:57
	Soft-realtime — это маркетинговое изобретение микрософта. Либо система гарантирует задержки, либо нет. Величины этих гарантированных задержек - дело десятое.
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Forth (ok), 06-Янв-20, 23:34
	Разница есть. Системы hard realtime ничего и никогда не должны пропускать. Потому что пропуск события в них это полный сбой. Самый набивший оскомину пример это кардиостимулятор. Если он не вовремя выдаст импульс или вовсе пропустит это может привести к остановке сердца.
	Ответить | Правка | Наверх | Cообщить модератору

	280. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–3 +/–
	Сообщение от антонимус (?), 07-Янв-20, 00:04
	>Самый набивший оскомину пример это кардиостимулятор. ОС общего назначения никогда не применяют в критических системах, связанных с жизнью человека. Вопрос закрыт.
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Forth (ok), 07-Янв-20, 09:46
	О том и речь. Hard-realtime это специально спроектированные системы, способные эти требования выдерживать. Linux это soft-realtime.
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от антонимус (?), 07-Янв-20, 00:12
	>Это финиш. Как не странно, в конечном счёте важно Лучше бы ты в lklm патчи присылал. Ты же обладаешь сакральным знанием: >Та же винда с незапамятных времён имеет возможность оптимизации, банальным переключением флажка в формочке
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	416. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от КО (?), 13-Янв-20, 15:28
	>Именно это общее время и есть самый главный показатель, Если оно правильно измерено. А если в одном случае в измеренное время паузу от вытеснения задачи, а в другом случае не считали, то это и было тем, что измерили в ходе эксперимента.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

68. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
Сообщение от Аноним (68), 06-Янв-20, 13:35
Линус - в своём репертуаре. Начиная со своего знаменитого спора с Таненбаумом. А ведь профессор оказался прав, как бы зомбикам(и) не внушалось обратное. В мире надёжности лучше - микро/экзо ядра, аппаратно разделённые адресные пространства процессов, и механизм сообщений над блкориующими каналами. Всё другое - костыли над костылями для скорбных умищем и танцы с бубном.
Ответить | Правка | Наверх | Cообщить модератору

	73. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 13:47
	И над этим всем великолепием зависла IRS таймера, переключающая контексты? ;)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (79), 06-Янв-20, 13:51
	Тот-то Столлман так Гурд и не дописал. А все потому что это ваше микроядро тупо сложно писать. А время программиста дороже машинного времени.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	104. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от zzz (??), 06-Янв-20, 14:49
	Линукс крутится - грубо, на 10 млн серверов. Это 20 млн процессоров, это $1000 каждый, это 20 млрд.долл. Время программистов дороже этой суммы? Rly?
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (156), 06-Янв-20, 17:03
	Лол один программист стоит 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 ядер. Просто купим побольше ядер и все будет пучком. Процедура подсчета чужих денег закончена.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 17:04
	https://www.amazon.com/Supermicro-F618R2-RT-Bay-Motherboard-...
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (182), 06-Янв-20, 18:18
	Глупость какая-то. Куча металлолома. 2 х 14 Тб HDD Toshiba в зеркале раз в 10 дешевле.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от zzz (??), 06-Янв-20, 18:40
	Если на разработку планировщика о 3 тыс строк (столько весит ULE) требуется отдел на 8 человек и три года разработки, то становится понятным, почему линуксячий код - такое фуфло, типовое обновление - прикручивание свистелок, а линукс называют конторой для отмывания бабла.
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

	191. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 18:51
	Этим и отличается суровый энтерпрайз от поделок Васяна. Васян может и напишет 3000 строк и они вполне вероятно заработают только когда это все навернется он будет не причем. А вот отдел это уже весомая величина там и виноватых можно найти и работать заставить. И сделать так чтобы было с перламутровыми пуговицами тоже к ним. И по хорошему если что-то годное выйдет они и в апстрим зальют. Но зачем когда ты можешь заплатить те же деньги шапке ака межбизмашу и все не критически острые углы ты можешь обходить покупая больше железяк. А уж что там в шапке напишут Линус уже написал что они там напишут.
	Ответить | Правка | Наверх | Cообщить модератору

	300. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от Аноним (299), 07-Янв-20, 03:33
	Уже написанный launchd когда внедрите? Или трех подходов оказалось недостаточно (что, впрочем, не помешало пытавшимся защитить на этой теме дипломы)?
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	352. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (352), 07-Янв-20, 19:20
	>> разработку планировщика о 3 тыс строк (столько весит ULE) > Уже написанный launchd когда внедрите? Начался юлеж. И да, опеннетчики, по причине ношения маечки с пингвинчиком и установленной в дуалбуте с виндой бубунточки отождествляющие себя с разработчиками - забавны.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Сишник (?), 06-Янв-20, 19:30
	При том, что эти сервера крутят в солидном % случаев скриптоту, претензия к неоптимизированности чего-то там в ядре просто смешна. Тем более что за линукс они и 1$ не платят.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	257. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от zzz (??), 06-Янв-20, 23:09
	Это именно то, чего вы хотели, чего теперь плакаться. А с другой стороны - что, у амазона или ойбиэм не нашлось бы лишних пары килобаксов, чтобы запилить я публичное ядро нормальный планировщик? Конечно же, нашлось бы. Просто им это - не надо. Они у себя втихую будут крутить закрытую инфраструктуру на нормальном планировщике, а остальные облизнутся. И так в линуксе со всем - что с планировщиком процессов, что с планировщиком вввода-вывода, что с сетевой подсистемой, что с файрволлингом - всё работает, но недоделанное, а доделать - не дают.
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 00:26
	> И так в линуксе со всем - что с планировщиком процессов, > что с планировщиком вввода-вывода, что с сетевой подсистемой, что с файрволлингом > - всё работает, но недоделанное, а доделать - не дают. Но забавляет вера неофитов, что лютая махровая проприетарщина, каковой ещё с конца девяностых является ведро пингвинукса — плод добровольного благотворительного вклада миллионов^W тысяч бескорыстных программистов в общее дело ради процветания всего человечества. Ибо свобода превыше всего!
	Ответить | Правка | Наверх | Cообщить модератору

	291. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 07-Янв-20, 00:57
	Если ты наивен, не думай, что все такие-же: https://www.linuxfoundation.org/membership/members/
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 07-Янв-20, 01:02
	И да, по исходникам таки работает GPL. Есличо.
	Ответить | Правка | Наверх | Cообщить модератору

	294. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от zzz (??), 07-Янв-20, 01:22
	Работают, работают. Только толку от GPL, если в апстрим никто ничего впилить не может без одобрения корпораций, которыми же решаются вопросы архитектуры. И на выходе мы получаем такую же винду, только с открытыми сырцами, а больше разницы никакой нет, потому что никакое комьюнити уже давно ничего не решает.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 07-Янв-20, 02:25
	Кто виноват и что делать - вечный вопрос :) А толку от GPL - закрыть можно не всё. А с "та же винда" - это ты загнул. Фиг ты в винде планировцик поменяешь :)
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от zzz (??), 07-Янв-20, 03:37
	И в линуксе - тоже фиг поменяешь.
	Ответить | Правка | Наверх | Cообщить модератору

	353. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от анонн. (?), 07-Янв-20, 19:29
	> И да, по исходникам таки работает GPL. Есличо. Только вот в современных облачных реалиях все что не AGPL - подарок корпоративным дядям из CloudFlare, Amazon, Google, Oracle и прочих. Впрочем, Tesla обещающая 6 лет как "совсем уже почти скоро откроем код!!" или китайцы, откровенно кладущие болт на все эти "заморочки бледнолицых демонов" - тоже неплохо демонстрируют, как это работает на самом деле.
	Ответить | Правка | К родителю #292 | Наверх | Cообщить модератору

	110. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–3 +/–
	Сообщение от Аноним (110), 06-Янв-20, 15:05
	Зато гугл взял и написал. И дрова будут. Одно дело какие-то nicheброды без денег и с GPL с хитрым простым как 3 копейки планом поиметь корпорации, а другое - корпорация с кучей денег, имеющая весь мир, делающая ОС в интересах своих таких же бизнес-партнёров.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	132. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:34
	> Зато гугл взял и написал. И дрова будут. Зуб даёте? :) > Одно дело какие-то nicheброды без денег и с GPL с хитрым простым > как 3 копейки планом поиметь корпорации, а другое - корпорация > с кучей денег, имеющая весь мир, делающая ОС в интересах своих > таких же бизнес-партнёров. По-моему: - план приписан (а по себе людей не судят); - лучше быть нищeбродом, чем ницшебродом (вроде гугля).
	Ответить | Правка | Наверх | Cообщить модератору

	245. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 22:11
	>Зато гугл взял и написал. И дрова будут. 1. Купил и дописал. 2. Дров не будет.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	130. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:32
	> В мире надёжности лучше Не с того начали.  Железо какое?
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	240. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 21:54
	Почитай ради интереса про стоимость переключения контекста на x86. Просто чтобы быть в теме, почему не взлетели микроядра на x86.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	243. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 22:07
	И чтобы два раза не вставать, в SPARC совсем другая ситуация. Была, к сожалению, ибо SPARC уже всё.
	Ответить | Правка | Наверх | Cообщить модератору

	391. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп.."	+/–
	Сообщение от Аноним (231), 09-Янв-20, 02:27
	С микроядрами все хорошо только на бумаге. По факту же, как только все сводится к очередям и сообщениям, получаем либо однопоточность, либо глубокое погружение в дивный мир распределённых алгоритмов.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

75. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
Сообщение от Annoynymous (ok), 06-Янв-20, 13:50
> Добавление специфичных оптимизаций, которые позволят снизить задержки в играх Google Stadia, могут повысить отзывчивость в конкретном случае, но скорее всего приведут к снижению эффективности планировщика в целом. Например, планировщик Windows ведёт себя лучше в обсуждаемых тестах, так как он значительно проще планировщика Linux и оптимизирован в основном для задач, специфичных для рабочего стола. Так может, так и надо делать? провести специфичную оптимизацию, вынести её в отдельный планировщик, а на серверах пусть крутится серверный.
Ответить | Правка | Наверх | Cообщить модератору

	99. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от ананим.orig (?), 06-Янв-20, 14:35
	Google Stadia — это и есть сервера. к тому же вам уже скомпилировали вантуз. покупайте и пользуйтесь.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (157), 06-Янв-20, 17:21
	А может лучше игроделы под google stadia пусть научаться в spinlock? Или используют что другое?
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	246. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 22:21
	>А может лучше игроделы под google stadia «Stadia предлагает мгновенный доступ к игре без необходимости загружать или устанавливать какие-либо игры». Сервис стал доступен 19 ноября 2019. Как заявляет компания, такая особенность позволяет подписчикам сервиса «стримить» игры на свои устройства в разрешении 4K с кадровой частотой 60 кадров в секунду. Красавцы. И пофиг, что при передаче по сети "мгновенный доступ" будет мягко говоря не совсем мгновенным :)
	Ответить | Правка | Наверх | Cообщить модератору

131. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от gfederix (ok), 06-Янв-20, 15:32
А сделал вывод, что нам не хватает планировщика, для рабочего стола...
Ответить | Правка | Наверх | Cообщить модератору

142. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
Сообщение от Аноним (140), 06-Янв-20, 16:26
В оригинальном посте автор звукового сервера JACK сказал несколько дельных вещей, за это ему, автору поста, ck и автору новости - спасибо
Ответить | Правка | Наверх | Cообщить модератору

144. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от Anonymoustus (ok), 06-Янв-20, 16:35
Где всезнающий пох? Эй, пох! Ты всё знаешь, подскажи решение бытовой задачки: - как под уже установленную и работающую винду (WS2003 SP2 R2) подсунуть второй HDD и сделать «зеркало» (RAID-1) с первым HDD? 3,5-дюймовых дискеток, чтоб установить оффтопик по-правильному, к сожалению, нету ни одной, купить по-быстрому негде (пламенный привет поклонникам взрывного прогресса инноваций). Если в интерфейсе RAID-адаптера (встроенный в мамку Адаптек <че-то там>, могу посмотреть детальней, если надо, но не думаю, что это на самом деле кому-то надо) попытаться соединить диски в массив, оффтопик на мгновение показывает BSOD (?) и сразу отправляет мать на перезагрузку. Если я руками положу внутрь уже установленной винды адаптековские дрова — она после перезагрузки их найдёт и свяжет с внезапно появившимся и ранее ей неизвестном массиве типа RAID-1? Или таки надо искать дискеты и всё делать заново по стандартной процедуре? Нет, пингвиниксов на этом сервере я не хочу, фрю тоже не хочу.
Ответить | Правка | Наверх | Cообщить модератору

	153. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (182), 06-Янв-20, 17:05
	> - как под уже установленную и работающую винду (WS2003 SP2 R2) подсунуть второй HDD и сделать «зеркало» (RAID-1) с первым HDD? https://www.sim-networks.com/wiki/create-software-raid-in-wi...
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 17:20
	Как-то слишком просто такая задача на нормальных ос требует жестких плясок в консоли с бубном.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (182), 06-Янв-20, 17:32
	Недавно понадобилось. Тоже удивился.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Не пох а ктото другой (?), 06-Янв-20, 17:36
	Какие жесткие пляски, дети? Одна строчка в консоли. Одна, Карл!
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	253. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (156), 06-Янв-20, 23:01
	А потом на загрузке будет у тебя mduuid not found и начинаются пляски)
	Ответить | Правка | Наверх | Cообщить модератору

	310. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (306), 07-Янв-20, 06:13
	Ты и в windows not found добьёшься, талант.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (182), 06-Янв-20, 17:43
	К сожалению, да. Под сервером Windows софтовый RAID без проблем конфигурируется после установки ОС. Под сервером Ubuntu нормальную установку софтового RAID (на этапе установки сервера) поломали, начиная с версии 16.04.3. Поэтому приходится ставить версию 16.04.2 для решения проблем, затем обновляться до актуальной 16.04 версии. То, что сделали в сервере, начиная с 18.04 версии, можно безобразием назвать - система нерабочая (в смысле софтового RAID).
	Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

	172. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (182), 06-Янв-20, 17:45
	ты не совсем прав. мы решили данную проблему. главное - вредные советы из интернета не читай.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Не пох а ктото другой (?), 06-Янв-20, 19:53
	Вы читать умеете? Человек хочет raid-1 после установки. Ты тут лепишь что-то про проблемы какого-то конкретного дистрибутива при _установке_. У вас что с причинно-следственными связями?
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	213. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Anonymoustus (ok), 06-Янв-20, 19:56
	>> - как под уже установленную и работающую винду (WS2003 SP2 R2) подсунуть второй HDD и сделать «зеркало» (RAID-1) с первым HDD? > https://www.sim-networks.com/wiki/create-software-raid-in-wi... В Windows 2003 такой функциональности нету в оснастке.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	167. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Не пох а ктото другой (?), 06-Янв-20, 17:33
	Тебе надо драйвер адаптека вручную поставить через управление компьютером/устройства. Когда поставишь указать что должен запускаться загрузчиком вместе с ядром Тут подробнее как: https://docs.microsoft.com/en-us/windows-hardware/drivers/if... Потом перегружаешься делаешь рейд из биоса и все будет хорошо при загрузке. Винда напишет, что найдено новое устройство. Задачка-то элементарная, позор не знать.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	174. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (182), 06-Янв-20, 17:49
	Могу сказать на твой совет - он вреден (хотя адаптека немного обогатит). Посмотрю на тебя, когда сломается материнка сервера, а при этом сервер уникальный и лет 5-6 уже не выпускается. Софтовый RAID под любой системой от аппаратуры практически не зависит - перекидываем диски и понеслась. В худшем случае сетевой адрес прописать.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Не пох а ктото другой (?), 06-Янв-20, 19:52
	Вреден кому? Я вопрошающему ответил, что ему делать надо, как понял его же вопрос. Человек конретную проблему хочешь решить, ему видней надо адаптек или нет.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (299), 07-Янв-20, 03:37
	А что, разве остались еще контроллеры, не использующие DDF?
	Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

	350. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 17:56
	> Тебе надо драйвер адаптека вручную поставить через управление компьютером/устройства. > Когда поставишь указать что должен запускаться загрузчиком вместе с ядром > Тут подробнее как: > https://docs.microsoft.com/en-us/windows-hardware/drivers/if... > Потом перегружаешься делаешь рейд из биоса и все будет хорошо при загрузке. > Винда напишет, что найдено новое устройство. > Задачка-то элементарная, позор не знать. Ну раз ты такой гуру… Давай-ка переформулирую. Винда во время загрузки показывает BSOD, если в адаптековском BIOS включить RAID. Просто включить, ага. Сообщение надо? Ну, на (я записал специально для тебя): STOP: 0x0000007B(0xF789EA94,0xC0000034,0x00000000,0x00000000) Прояснилось? Не? ;) Я хочу, чтобы винда перестала падать в BSOD, когда я пытаюсь просто включить RAID (и добавить в него второй HDD). Как это сделать?
	Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

	357. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Не пох а ктото другой (?), 07-Янв-20, 21:01
	Мне и раньше все было понятно и проблема твоя синим по белому написана, да вот ты написанному не внемлешь, балбес. Проблема твоя: не найден загрузочный диск, оно и неудивительно, ведь драйвера-то нет! :) Еще раз: поставь драйвер, который нужен. Это дополнительный драйвер, не помню как у адаптека называется,fake-raid или еще как. Затем его надо включить в обязательный для загрузчика, что сложного? Хорошо, если не понимаешь, то вот тебе второй способ, делаешь _новый_ _отдельный_ raid-1 из одного диска, перегружаешься, чтобы драйвер был поставлен как надо. Ставишь драйвер, если попросит (может и не попросить, так и будет неизвестное устройство). Теперь raid этот можно удалить и делать что собирался. Драйвер уже будет стоят как надо. Фишка второго способа в том, что драйверы дисков всегда обязательные для загрузки на первой стадии ntldr, даже если диск не загрузочный. Все это работает, мать его, для _любых_ таких случаев и кажись еще с windows 2000.
	Ответить | Правка | Наверх | Cообщить модератору

	361. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 21:24
	> Мне и раньше все было понятно и проблема твоя синим по белому > написана, да вот ты написанному не внемлешь, балбес. Проблема твоя: не > найден загрузочный диск, оно и неудивительно, ведь драйвера-то нет! :) > Еще раз: поставь драйвер, который нужен. Это дополнительный драйвер, не помню как > у адаптека называется,fake-raid или еще как. Затем его надо включить в > обязательный для загрузчика, что сложного? Винда была установлена на отдельный винт, а не на массив, поскольку не было дискеты, дабы подсунуть ей драйвер. Всё работает, но как обычный ПК. RAID-функциональность отключена в BIOS контроллера, инача винду нельзя было установить. Хочется теперь подсунуть второй диск и сделать RAID-1. Для этого в прошивке контроллера требуется включить RAID-функциональность. Если её включить, винда валится в BSOD. Ещё раз, медленно: уже установленная винда видит загрузочный диск при любых настройках, но показывает BSOD, если попытаться включить RAID. Если выключить, снова всё работает в режиме ПК. Как сделать? Я не понимаю. А дискеты для правильной установки — нету. Нету дискеты. Замкнутый круг. Будет дискета — не будет вопросов. :)
	Ответить | Правка | Наверх | Cообщить модератору

	365. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Не пох а ктото другой (?), 08-Янв-20, 00:04
	Еще раз, медленно: мне кристально ясно что у тебя не так. Если бы этот сервер был щас передо мной, понадобилось бы минут 5 (без учета времени на загрузку/пеерзагрузку), чтобы все сделать как надо. Как работает гребаный fake-raid: Биос (обычный ибо нет никакого контроллера на самом деле), если включен fake-raid, работает с дисками как с рейд компонентами и если рейд собран выдает его как обычный биос девайс. Казалось бы, че бы не работать, но вот беда, обычный сата драйвер в винде не найдет там MBR, потому что там вместо него метаданные рейда. Потому загрузчик ntldr, втащив все дрова, каким полагается быть на _загрузке_ толкает ядро и дрова опрашивают все что видят и вуаля, драйвер сата диски видит, да MBR с них нечитается! Итого все что надо сделать это драйвер fake-raid тот самый, который надо было на дискете пихать в самом начале, засунуть в систему и выставить правильный тип загрузки - вместе с загручиком. Аналогично если ты хочешь с фейкового рейда съехать на обычный сата, скорее всего достаточно будет скопировать диск побайтно и включить обычный IDE режим в биосе. Если хочешь как положено AHCI, то сюрприз, ahci драйвер в винде также по дефолту не загружается ntldr. :) Все дело в долбанном типе загрузки драйвер. Тоже самое веселье у эникев, которые поставили систему в IDE режиме контроллера, а потом включили AHCI, например потому что впихнули новенький SSD и оппаньки, тот же самый детский BSOD, что у тебя.
	Ответить | Правка | Наверх | Cообщить модератору

	368. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 08-Янв-20, 01:21
	1. У меня SCSI, а не SATA. Перепиши свои умные советы с учётом этой досадной мелочи. ;) 2. Синий экран я уже победил. Включил в БИОСе только канал B (на котором нет дисков) контроллера. Винда после загрузка нашла новое устройство и всосала нужный драйвер. Этот же драйвер принудительно скормил устройству канала A. Пара перезагрузок, между которыми в БИОСе включил RAID-функцию для канала А, и всё стало хорошо: ОС видит два RAID-контроллера (соответствуют каналам A и B). 3. Но массив не делается. Точнее, он делается, но после его постройки — прекрасный чорный экран с многообещающей надписью "Operating System Not Found". Вопрос остаётся тот же: какие мне надо совершить манёвры, чтобы установить винду без дискеты с дровами, которой нету, но чтобы сделать зеркало уже после установки виндов? ЗЫ Контроллер называет себя Adaptec Ultra320 SCSI AIC-7902B.
	Ответить | Правка | Наверх | Cообщить модератору

	376. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Не пох а ктото другой (?), 08-Янв-20, 11:48
	Я терпеливый человек, но у терпения предел есть и он заканчивается. Какая разница между scsi и sata в данном случае? Проблема остается ровной той же самой, драйвер нужен на этапе загрузки. Я все расписал по этому поводу, как это работает. Больше по загрузке и драйверам распинаться не буду. Хотя судя по пункту 2, ты таки справился. Рождественское чудо, не иначе. Маневры все теже. Причем если операция создания рейда была неразрущающей, то загрузчик и прочее должны быть в полном порядке. Здесь похоже достаточно порядок загрузки в биосе выставить верный. Винда 2003 не умеет грузится не с 0 диска биоса. Если все равно не выходит, то fixboot, fixmbr помогут. Подробнее тут: https://support.microsoft.com/en-us/help/326215/how-to-use-t... Если ты и после этих объяснений не справишься, то пора тебе подумать о смене профессии.
	Ответить | Правка | Наверх | Cообщить модератору

	377. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 08-Янв-20, 14:18
	А консоль восстановления увидит диски в массиве? Попробуй подумать ещё разок. Не огорчай Даннинга и Крюгера, аноним. Попробуй читать, что пишут люди, а не заниматься копипастой общеизвестных банальностей из Гугла. Нет у меня дискеты. Понимаешь? Если бы дискета была, я бы этот драйвер подсунул винде по F6, как и положено. Если ты не знаешь, как решить задачу, то проходи мимо. Денег нет, но вы держитесь, и всего вам хорошего.
	Ответить | Правка | Наверх | Cообщить модератору

	381. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Не пох а ктото другой (?), 08-Янв-20, 15:40
	Конечно увидит, если знать что делать. Зачем тебе дискета? Для того, чтобы консоль увидела диски надо добавить драйверы адаптек в образ и это совсем просто. Но ты же только про Даннинга и Крюгера поговорить горазд, вместо освоения азов своей профессии. Наметки дал напоследок, авось справишься. Хотя врядли. Адью.
	Ответить | Правка | Наверх | Cообщить модератору

	384. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 08-Янв-20, 21:19
	> Конечно увидит, если знать что делать. Зачем тебе дискета? Для того, чтобы > консоль увидела диски надо добавить драйверы адаптек в образ и это > совсем просто. > Но ты же только про Даннинга и Крюгера поговорить горазд, вместо освоения > азов своей профессии. > Наметки дал напоследок, авось справишься. Хотя врядли. > Адью. Мальчик, ты дурак?
	Ответить | Правка | Наверх | Cообщить модератору

	363. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 23:08
	Впрочем, драйвер винде я таки подсунул. Попробую собрать диски в массив и после отпишу, что получилось.
	Ответить | Правка | К родителю #357 | Наверх | Cообщить модератору

	385. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от PnD (??), 08-Янв-20, 21:30
	Эту даже я до сих пор помню (а гугл и не забывал): 0x0000007B INACCESSIBLE_BOOT_DEVICE Решается вкручиванием правильного драйвера, как и написано выше. В линухах модуль прикручивают к initrd(initramfs), и не всегда так уж тривиально (надо сначала выяснить мнение дистростроителей что куда класть). В винде суть процесса не меняется, но придётся освоить их терминологию и тулсет.
	Ответить | Правка | К родителю #350 | Наверх | Cообщить модератору

	388. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 08-Янв-20, 23:32
	> 0x0000007B INACCESSIBLE_BOOT_DEVICE Нет, синий экран у меня с другим сообщением. Я уже разобрался с синим экраном. Вопрос: что и как делать дальше. > Решается вкручиванием правильного драйвера, как и написано выше. Выше ничего по существу-то и не описано, лишь копипаста банальностей. Вкручивается драйвер либо со специально обученной дискеты во время установки, либо вшивается в дистрибутив до установки. Оба способа в моём случае не подходят. Какие есть ещё? Вот смотри, что я имею на данный момент. Есть установленная (как для ПК) винда. Два диска подключены к контроллеру на один канал (A), но не собраны в RAID-1. Полностью и правильно установленная винда знает про рейд-контроллер и схарчила для него правильный драйвер. Что будет, если я в БИОСе контроллера попробую собрать массив?
	Ответить | Правка | Наверх | Cообщить модератору

	397. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от PnD (??), 09-Янв-20, 10:22
	> Вот смотри, что я имею на данный момент. Есть установленная (как для > ПК) винда. Два диска подключены к контроллеру на один канал (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) местами надо вычитывать побайтно чтобы понять что за х*ня. Но инструментарий — доступнее.
	Ответить | Правка | Наверх | Cообщить модератору

	413. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 09-Янв-20, 23:59
	В общем, я эту траблу победил без дискеты. По пунктам. 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. Фейл моей предыдущей попытки произошёл из-за выбора в адаптековском меню разрушающего создания рейд-массива. «Что-то накатило…»
	Ответить | Правка | Наверх | Cообщить модератору

	323. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 09:56
	Скорее всего, я раньше куплю флопик и пачку дискет, чем дождусь дельного совета от опеннетовских икспердов. ;) ЗЫ И отдельный аппаратный контроллер, а лучше два.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	343. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (343), 07-Янв-20, 14:37
	Никогда не используйте софтварный 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 - драйверы нужно удалять вручную и потом еще вычищать из реестра, в случае переноса на реальное железо.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	347. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 07-Янв-20, 17:46
	> Никогда не используйте софтварный RAID в Windows(вне зависимости от реализации), то же > самое и с "железным" без энергонезависимого кэша. Думаю, что ты стопроцентно прав, анонимный брат. Я уже в поиске подходящего железного сабжа с энергонезависимым кэшем. > Данные вы конечно не потеряете, Уже потерял. По какой-то причине необратимо (?) деградировала файловая система. Поскольку на машине не было ничего критически жизненно важного, то инцидент не обернулся трагедией, но заставил задуматься.
	Ответить | Правка | Наверх | Cообщить модератору

	375. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (343), 08-Янв-20, 11:30
	Это каким образом вам удалось потерять данные с зеркала? Тома intel matrix/rapid видны из linux  или например в acronis, данные можно спасти. в худшем случае придется повозиться с определением на каком из дисков зеркала актуальные данные.
	Ответить | Правка | Наверх | Cообщить модератору

	378. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Anonymoustus (ok), 08-Янв-20, 14:24
	> Это каким образом вам удалось потерять данные с зеркала? Тома intel matrix/rapid > видны из linux  или например в acronis, данные можно спасти. > в худшем случае придется повозиться с определением на каком из дисков > зеркала актуальные данные. Это отдельная история, но я счёл её малоинтересной для опеннетовского анонима. Впрочем, если спросили, то напишу. Данные потерялись в ходе операции «Очистка диска». Файловая система по какой-то причине начала разваливаться. Из двадцати, ЕМНИП, гигов файлов осталось около трёх. После перезагрузки винда не нашла свой hal.dll и ещё кучку нужных для себя файлов. Поскольку ничего существенного после этого на диски не писалось, то я вытащил то, что лежало в профиле юзера, и ещё кое-что сверху. Поскольку ничего такого уж важного на этой машине не было, то восстановление её данных не представляло значительного интереса. ЗЫ Частично сломались файловые таблицы, если вкратце.
	Ответить | Правка | Наверх | Cообщить модератору

145. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
Сообщение от all_glory_to_the_hypnotoad (ok), 06-Янв-20, 16:36
> игры выполняются на GPU в облачном окружении, а клиенту в потоковом режиме лишь транслируется содержимое экрана ... задержки, превышающие миллисекунду, становятся заметны. В гугл стали набирать на работу клоунов, причём целыми командами.
Ответить | Правка | Наверх | Cообщить модератору

	155. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (182), 06-Янв-20, 17:08
	Наполеон ответил http://www.inpearls.ru/146075
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (156), 06-Янв-20, 17:18
	А стадо баранов возглавляемое бараном? И по какой методике априорно производить оценку кто лев, а кто баран? А если оценку давать по результатам то какой смысл в этой фразе?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 06-Янв-20, 17:28
	Тут, к сожалению, стадо баранов под руководством барана против законов физики.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	248. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 22:38
	Ну почему к сожалению, физике пофиг, бараны против ейных законов или единороги. Фейл будет знатный :).
	Ответить | Правка | Наверх | Cообщить модератору

175. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от Аноним (175), 06-Янв-20, 17:52
Еще один мудила из нижнего тагила пишет игры на ОС общего назначения. Dа на месте Линукса я бы ему с ноги голову втащил - козлу. "... автор теста попытался возразить Линусу, указав на то, что применение собственных систем блокировки на базе spinlock часто используется на практике в играх, так ..." На практике нужно взять систему реального времени (что-то на подобии существовавшего когда-то DOS/DMPI) и разрабатывать только одно приложение где нет планировщика процессов/потоков вообще. Вот и решение всех проблем современных игроделов, но даже большие игроделы такие слабаки в тех. плане, что не могут это уже который год сдлеать. Что Xbox сидит на Widnwos, что PS сиит на FreeBSD ядре. Слабаки.
Ответить | Правка | Наверх | Cообщить модератору

	184. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (158), 06-Янв-20, 18:29
	Игры сейчас уже не те, они полагаются именно на поведение планировщиков. Вон даже в одноядерном режиме игры сейчас не работают, какое реальное время? Какое реальное время на 64 битах?
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (299), 07-Янв-20, 03:40
	> На практике нужно взять систему реального времени (что-то на подобии существовавшего когда-то DOS/DMPI) и разрабатывать только одно приложение где нет планировщика процессов/потоков вообще. И сразу же пойти на SO с вопросом "как собрать проект Unity под DOS?"
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

180. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+10 +/–
Сообщение от Аноним (-), 06-Янв-20, 18:12
Товральдс Мужик. Поставил зарвавшегося юнца на место.
Ответить | Правка | Наверх | Cообщить модератору

	203. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от псевдонимус (?), 06-Янв-20, 19:21
	Юнца поставил, молодец против овец. Зато против рыжего гремлина и своей дочурки он сам овца.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
	Сообщение от Аноним (-), 06-Янв-20, 21:34
	Вот здесь согласен. Батя толжен быть Батей прежде всего в семье, и ставить зарвавшихся дочyрoк на место, пока им окончательно не промыли мозги этими лгбт-ценностями. К сожалению, здесь Линус пpocрал время...
	Ответить | Правка | Наверх | Cообщить модератору

192. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
Сообщение от user90 (?), 06-Янв-20, 18:53
>  негативно сказываются на работе игр, создаваемых для сервиса Google Stadia Чииго, бл*ть?? Вот нахрен мне это знать?)) Из всех сервисов гугла интересны только гмайл (больше по привычке), и поиск, из-за адекватно работающих операторов включения/исключения, которые в х*яндексе уже много лет как сломаны в угоду толпе. Все, остальное таак пофиг..
Ответить | Правка | Наверх | Cообщить модератору

	285. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (175), 07-Янв-20, 00:17
	Зря ты так. Тут вообще хорошая идея в основе лежит. Идея в том, что срать на чем там все это написано, срать на чем оно там работает и какой там планировщик. Игра должна быстро работать и красиво рисовать, а ты только видеть картинку и управлять поведением. Отличная идея которая поставит всех игроделов перед серьезными вопросами выбора платформ и т.д. возможно даже что-то разработают под это дело полезное.
	Ответить | Правка | Наверх | Cообщить модератору

	326. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от whiplash (?), 07-Янв-20, 11:45
	все там нормально в яндексе
	Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

193. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от Корец (?), 06-Янв-20, 18:53
Вот яркий пример того, что сейчас происходит и не только в гейдеве. Вообще не знаю, что нас ждёт в будущем, когда такие, как Торвальдс, отойдут от дел.
Ответить | Правка | Наверх | Cообщить модератору

	196. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от user90 (?), 06-Янв-20, 18:59
	В будущем тебе будет не до этого, чувак, гарантирую!)) Да даже в 2020ом..
	Ответить | Правка | Наверх | Cообщить модератору

244. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
Сообщение от Аноним (244), 06-Янв-20, 22:08
> планировщик Windows ведёт себя лучше в обсуждаемых тестах, так > как он значительно проще планировщика Linux и оптимизирован > в основном для задач, специфичных для рабочего стола. Как будто десктоп - это что-то плохое. > Линус возразил, что планировщик Linux является универсальным, > оттачивался десятилетиями и оптимизирован не только для > рабочего стола и игр, но и для других видов нагрузки, например, > для серверных систем. А напаркуа мне "серверные системы" на домашнем компе?! Выше в каментах правильно сказали - под десктопы, игры и сервера нужно делать разные планировщики, а не скрещивать ежа с ужом и потом хвастаться этим франкенштейном.
Ответить | Правка | Наверх | Cообщить модератору

	247. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от антонимус (?), 06-Янв-20, 22:27
	> А напаркуа мне "серверные системы" на домашнем компе?! Паркуатор, вырыгай кактус и одомашнивай комп. Тебе никто ничего не обещал и не должен. Ты мимикрокодил и интересен только корпорастам. Оплачивай хотелки. Или разработкой или дензнаками :)
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (317), 07-Янв-20, 09:17
	Привет тебе от Коливаса :)
	Ответить | Правка | Наверх | Cообщить модератору

251. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от Аноним (156), 06-Янв-20, 22:58
Один человека говорит что играть в футбол на траве гораздо удобнее в бутсах, а ему говорят что валенки гораздо универсальные. Все в них ходят они проверены годами при желании ты можешь даже сам их свалять. Так что помолчи юнец нам лучше знать. А он им валенки и игра в футбол на траве не совместимы. А ему такие чувак шипы приделывать к валенками это моветон. Да и кроссовки из валеной шерсти не удобные, мы эксперты мы лучше знаем. Учи матчасть нуб. Погодите, но все кроме вас играют в футбол на траве в бутсах. А нам и в валенках тоже норм играть в футбол на траве. Универсально и проверено иди мальчик гуляй в своих бутсах, ты не эксперт.
Ответить | Правка | Наверх | Cообщить модератору

	259. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (254), 06-Янв-20, 23:22
	Ну а что же тогда мешает играть в бутсах этому господину?
	Ответить | Правка | Наверх | Cообщить модератору

	367. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (367), 08-Янв-20, 00:32
	Так он играет в бутсах в другой системе, подходит к мистерам в валенках и говорит что в футбол надо в бутсах. А ему отвали юнец мы суровый интерпрайз нам только валенки. А если в футбол поиграть то тоже валенки. И не учи нас играть в футбол.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (254), 06-Янв-20, 23:25
	А На модном го и Данте если бутсы запилить - вообще все летать будет
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	262. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Ordu (ok), 06-Янв-20, 23:27
	> Один человека говорит что играть в футбол на траве гораздо удобнее в бутсах, а ему говорят что валенки гораздо универсальные. Все в них ходят они проверены годами при желании ты можешь даже сам их свалять. Так что помолчи юнец нам лучше знать. Не, ты неверно проводишь аналогию, если уж проводить, то было примерно так. Один человек сказал, что в футбол на траве удобнее играть в бутсах, потому что в бутсах не страшен глубокий снег. А ему объяснили, что снегоизоляционные свойства бутс он мерял совершенно неправильно, и играть в бутсах на траве удобнее по несколько иным причинам. Если же без аналогий, то чувак говорил, что мьютексы быстрее, чем спинлоки, поэтому надо использовать мьютексы в играх. Пришёл Торвальдс и объяснил ему, что в играх надо использовать мьютексы, а не спинлоки, но по несколько иным причинам.
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	341. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (341), 07-Янв-20, 13:58
	Как же тогда футболисты играют на снегу в футбол в бутсах, а не в валенках? Бутсы есть и для снега и для льда и с изоляцией там все в порядке. Ваши Линусы и прочие иксперды в футбол на снегу то никогда не играли в бутсах. Да даже в валенках, сидят себе кодят света белого не видят.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 07-Янв-20, 15:19
	> Как же тогда футболисты играют на снегу в футбол в бутсах, Ты уж определись, они играют в футбол на траве? Или в футбол на снегу?
	Ответить | Правка | Наверх | Cообщить модератору

	366. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (367), 08-Янв-20, 00:29
	Это ты начал про снег. А в футбол и на траве и на снегу бутсы то что доктор прописал. А ваш Линус просто не умеет в футбол вот и все.
	Ответить | Правка | Наверх | Cообщить модератору

	369. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Ordu (ok), 08-Янв-20, 01:52
	> Это ты начал про снег. А в футбол и на траве и > на снегу бутсы то что доктор прописал. Да, ты верно подметил. По обоим пунктам. Теперь тебе осталось подметить, что довольно странно доказывать, что валенки не подходят для футбола на траве из-за того, что бутсы лучше бегают по снегу. Когда ты поймёшь это, ты поймёшь чем моя аналогия отличается от твоей.
	Ответить | Правка | Наверх | Cообщить модератору

	383. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (383), 08-Янв-20, 16:03
	Единственная этом случае правильная аналогия это что в бутсах неудобно разгружать вагоны. А валенки и разгрузка вагонов проверенная годами связка.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от антонимус (?), 06-Янв-20, 23:53
	Один человека говорит, что запускать компьютерные игры - это основная обязанность ОС компьютера. Дальше можно дописать самостоятельно...
	Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

	331. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (341), 07-Янв-20, 12:56
	Я и сам раньше так думал)
	Ответить | Правка | Наверх | Cообщить модератору

258. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+5 +/–
Сообщение от Аноним (263), 06-Янв-20, 23:20
Линус подтвердил что линукс - серверная ОС, которая не подходит для десктопа. Таким образом все кто портируют игры и десктоп-приложения на линукс по мнению Линуса - дэбилы. Тут сириус бизнес и энтерпрайз а не бирюльки. Ну это в принципе всё объясняет - и дизайн линукса, и нестабильный API, и крайне хреновую графическую подсистему, и убогую или отсутствуюущую поддержку устройств потребительского класса, и отсутствие обработки OOM, и тормоза при копировании с флэшки (12309), и многое другое. Всё это просто Линусу и интырпрайзу не нужно. Вам тут не десктоп, всего вам доброго и хорошего настроения.
Ответить | Правка | Наверх | Cообщить модератору

	261. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–2 +/–
	Сообщение от Аноним (158), 06-Янв-20, 23:25
	Ты повторяешь мифы 20 летней давности, уже лет 15 как это всё не актуально.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (263), 06-Янв-20, 23:34
	Да я это у себя всё наблюдаю. Начиная со жрущей CPU как не в себя графики, кривой поддержки звука и видео, даже чёртов браузер умудряется работать хуже чем в винде. Браузер! Ну зато можно в одну команду поставить тридцать три сервера в тридцати трёх контейнерах. Так что кому что важнее.
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (11), 06-Янв-20, 23:39
	а я такого у себя не наблюдаю попробуйте  докер и кубернетис с виртуалками удалить тогда будет ок
	Ответить | Правка | Наверх | Cообщить модератору

	268. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+2 +/–
	Сообщение от Аноним (11), 06-Янв-20, 23:42
	> Начиная со жрущей CPU как не в себя графики, кривой поддержки звука и видео, даже чёртов браузер умудряется работать хуже чем в винде. хз ютуб работает ок и не лагает - комп ноут 10 летней давности, не жужжит
	Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

	269. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (158), 06-Янв-20, 23:44
	Это проблемы кривых браузеров, не хотят их разработчики они линукс за платформу считать. У хромиума получше — гугл продаёт девайсы с линуксом всё-таки. >жрущей CPU как не в себя графики У нвидии всё норм что 15 лет назад, что сегодня. >кривой поддержки звука и видео Опять проблемы браузеров и криворуких кодеров. Я вот не использую пульсу и всё прекрасно. С видео у нвидии опять же всегда всё норм, загрузка процессора доли процента на 4к контенте. Теперь и bumblebee не нужен на лаптопах больше, вообще замечательно.
	Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

	282. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (263), 07-Янв-20, 00:07
	> Это проблемы кривых браузеров, не хотят их разработчики они линукс за платформу считать. У хромиума получше — гугл продаёт девайсы с линуксом всё-таки. Пользователю как-то всё равно с чьей стороны проблема. Если браузер хреново работает в данной ОС (а это 90% всего использования десктопа) - такая ОС ему не нужна. Пусть себе крутится на сервере. > У нвидии всё норм что 15 лет назад, что сегодня. К сожалению нет, по-крайней мере в ноутбуках. Теперь графику частично затащили в монолитное ядро и в сочетании с закрытым блобом система при багах в графике просто умирает. Даже не kernel panic, а просто хард лок с чёрным экраном. В лучшем случае падают иксы, но так как все пользовательские приложения - графические, то это вот как-то вообще не утешает. То что там продолжают крутится демоны при падении графики - это прикольно, но для пользователя десктопа бесполезно от слова совсем. Проиграть полноэкранное видео без микро-лагов - проблема, подключить внешний телевизор - проблема, запустить игру - проблема (с этим стало получше, но далеко не везде без танцев с бубном работает). Да, можно с этим мириться как со жмущими ботинками, но это не нормальная и не здоровая ситуация. >Опять проблемы браузеров и криворуких кодеров. Я вот не использую пульсу и всё прекрасно. Пользователю как-то всё равно с чьей стороны проблема. Помню была где-то смешная проблема, что кодеры подсистемы звука под линукс признались что не могут решить проблему с несколькими звуковыми выходами на ноутбуках если у них одинаковые идентификаторы (например встроенные колонки и внешний аудио-выход). Так и писали - мол, мы таким не пользуемся, а если вам очень надо - вот вам язык и пишите сами себе кусок драйвера под свой ноутбук.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (327), 07-Янв-20, 11:57
	>  Даже не kernel panic, а просто хард лок с чёрным экраном. В лучшем случае падают иксы А, то есть сейчас даже старый добрый сисрку комбинация не спасает? Только кнопкой питания исправлять ситуацию? Да это прогресс прям.
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 23:58
	>Да я это у себя всё наблюдаю. Ваше мнение чрезвычайно важно участникам форума. Продолжайте наблюдение...
	Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

	320. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (317), 07-Янв-20, 09:33
	Вот человек наблюдает, делится информацией, другие читают об этом, узнают, что не у всех всё хорошо работает. Возможно, для тех кто это читает, есть какая-то польза. А какая польза от вашего сообщения? !!!ВОПРОС РИТОРИЧЕСКИЙ!!!
	Ответить | Правка | Наверх | Cообщить модератору

	400. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (93), 09-Янв-20, 15:06
	Если что-то плохо работает, об этом надо багрепорты писать. Но, конечно, если ни знания матчасти для анализа ситуации и выявления reproducible test case нет, ни знания английского, чтобы багрепорт сформулировать - тогда, да, все, что остаётся - это жаловаться на опеннетике в обществе таких же необразованных.
	Ответить | Правка | Наверх | Cообщить модератору

	410. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (410), 09-Янв-20, 17:57
	>Если что-то плохо работает, об этом надо багрепорты писать. Зачем вы пишите очевидные вещи? Это и так понятно! >Но, конечно, если ни знания матчасти для анализа ситуации и выявления reproducible test case нет, ни знания английского, чтобы багрепорт сформулировать - тогда, да, все, что остаётся - это жаловаться на опеннетике в обществе таких же необразованных. Спасибо, насмешили.
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (254), 06-Янв-20, 23:30
	Винда 10 грузится минут 10 и тормозит На линуксе загрузка меньше минуты Пользователь hdd и старого компа с дуал бут Апргрейдится не вижу смысла линукс работает вполне оперативно и стабильно
	Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

	274. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (158), 06-Янв-20, 23:50
	Можно попробовать отключить гибридную гибернацию или как её там у десяточки, так она и весь час грузиться будет. Не вижу смысла это обсуждать, как система линукс для пк куда больше подходит. Если в голове не совсем хлебушек, так он ещё и надёжней — не придётся регулярно переустанавливать, как виндоус. Впрочем, это зависит от дистра.
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от unnamed11111 (?), 07-Янв-20, 00:05
	что за комп? в десятке надо сразу обязательно выключать "защитник" и не ставить другие "защитники" - этот говнософт сжирает вообще все ресурсы.
	Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

	336. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (11), 07-Янв-20, 13:19
	какойто 6 ядерный amd купленый лет 10 или больше назад 8gb памяти hdd диск защитник отключен конечно - не помогает
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от unnamed11111 (?), 07-Янв-20, 21:21
	"какойто 6 ядерный amd купленый лет 10 или больше назад 8gb памяти hdd диск" + отключен "защитник". и 10 минут загрузки? ты что-то делаешь не так. на core 2 duo с 4gb памяти и жестким на 7200 грузится гораздо быстрее.
	Ответить | Правка | Наверх | Cообщить модератору

	362. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от unnamed11111 (?), 07-Янв-20, 21:25
	Вообще одна из больших проблем винды - она не настроена изнанчально и настраивается хоть как-то только минимум в про версии через политики - внезапно, для дома ось проблематично использовать.
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (249), 07-Янв-20, 03:00
	Ставь 1909 со всеми обновлениями. Всё что позже 15хх мсовцы разломали и только недавно привели хоть в какой-то порядок.
	Ответить | Правка | К родителю #264 | Наверх | Cообщить модератору

	338. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (11), 07-Янв-20, 13:22
	я редко загружаю windows 10 но когда это делаю - система всегда любезно предлагает обновится, сидишь потом пару часов и ждеж пока обновляется никаких улучшений в плане повышения производительности разумеется нет - да я не ожидаю этого
	Ответить | Правка | Наверх | Cообщить модератору

	277. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 06-Янв-20, 23:55
	Линус подтвердил только то, что если хочешь написать правильный софт, учи документацию. А ты подтвердил свою предвзятость, демагог :)
	Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

272. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
Сообщение от Аноним (263), 06-Янв-20, 23:47
На самом деле Линус не объективен по этому вопросу и пытается давить авторитетом и руганью, а не разумными доводами. У него есть личное мнение и мнение это что локи в юзерспейсе - зло и "неправильно". Вот история 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 и ему плевать на логику если у него есть Мнение по какому-либо вопросу.
Ответить | Правка | Наверх | Cообщить модератору

	276. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (11), 06-Янв-20, 23:54
	чтоже мешает такой корпорации как google c немерянными бюджетами сделать все правильно - и сделать свой форк? и раздавать и обновлять совершенно бесплатно эту чудесную правильную ось всем подписчикам google stadia абсолютно бесплатно и неограниченно в рамках действия срока подписки?
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от антонимус (?), 07-Янв-20, 00:00
	гуглу мешает авторитет Торвальдса, не иначе :)
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (263), 07-Янв-20, 00:09
	Да ничего не мешает. Так же как они допатчили линукс до нужного им Android`а, так и сделают свою StadiaOS при необходимости. А Линус так и будет слюной брызгать.
	Ответить | Правка | К родителю #276 | Наверх | Cообщить модератору

	334. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (11), 07-Янв-20, 13:14
	что же они этого еще не сделали? сервис уже запустили вроде. но вместо того чтобы сделат ь как надо - пытаются найти виноватых в лице разработчиков ядра линукс.
	Ответить | Правка | Наверх | Cообщить модератору

	311. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от Аноним (306), 07-Янв-20, 06:20
	На самом деле чувак перед тестами даже man не прочитал где всё это описано прямым текстом в разделе NOTES: http://man7.org/linux/man-pages/man3/pthread_spin_init.3.html Абсолютная некомпетентность.
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

	339. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (-), 07-Янв-20, 13:23
	А кто объективен? Анон с пoпeннета?
	Ответить | Правка | К родителю #272 | Наверх | Cообщить модератору

313. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
Сообщение от Аноним (313), 07-Янв-20, 08:31
Гуглстадия там же и гуглгласс и еще миллион проектов от гугла
Ответить | Правка | Наверх | Cообщить модератору

	332. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (341), 07-Янв-20, 13:04
	Линус определенно приложил к этому руку. То нвидии палец покажет, то гуглу вот таким изощренным методом. Не любит он большие корпорации почему то, ой не любит.
	Ответить | Правка | Наверх | Cообщить модератору

	337. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (-), 07-Янв-20, 13:21
	Гуглстадия... через год закроется, как 90% их проектов.
	Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

	342. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (341), 07-Янв-20, 14:01
	Как 146% скорее просто переименуют. А стриминг есть не только от гугла.
	Ответить | Правка | Наверх | Cообщить модератору

	372. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (371), 08-Янв-20, 06:38
	Нет. Закроют. Т.к. стримминговый сервис нужен, как корове пятое седло. Вот когда вся сетевая инфраструктура перейдет на квантовую телепортацию, тогда стримминговые сервисы и взлетят. :-)
	Ответить | Правка | Наверх | Cообщить модератору

	382. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (383), 08-Янв-20, 15:58
	Нет
	Ответить | Правка | Наверх | Cообщить модератору

340. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
Сообщение от darkshvein (ok), 07-Янв-20, 13:51
>Например, планировщик Windows ведёт себя лучше в обсуждаемых тестах, так как он значительно проще планировщика Linux и оптимизирован в основном для задач, специфичных для рабочего стола. пф, почему бы не распилить планировщик на два других? даже такое хомоюзер, как я, и то сможет чекнуть нужную галочку в .конфиг либо скачать пакет ядра с нужным планировщиком. я сильно сомневаюсь, что хоум-юзеры линукса держат одновременно на домашних тачках серверные аппсы.
Ответить | Правка | Наверх | Cообщить модератору

	373. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Аноним (371), 08-Янв-20, 06:39
	1. Монолит 2. Нафига?
	Ответить | Правка | Наверх | Cообщить модератору

346. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–4 +/–
Сообщение от Аноним (346), 07-Янв-20, 15:43
Что ж, Линус пошёл в отрицание, закономерная реакция. Отзывчивость Линукса на десктопах все же страдает
Ответить | Правка | Наверх | Cообщить модератору

	390. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (231), 09-Янв-20, 02:21
	Страдает, только проблема там совсем другая.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема