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

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

Сообщения

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

2. Сообщение от Аноним (2), 06-Янв-20, 10:23	+23 +/–
Ничего не понял из текста, но я более за Линуса. гугл в утиль.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #6, #91, #93, #140, #207, #329, #348, #387, #393

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. Сообщение от Аноним (26), 06-Янв-20, 11:21	+5 +/–
Забавно читать про "более простые планировщики". Знания внутренностей ядра 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, #42, #43, #47, #97, #146, #226, #229, #256

29. Сообщение от anonymous (??), 06-Янв-20, 11:32	+4 +/–
>> сам Линус >> говорит, что 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ообщить модератору
Родитель: #10 Ответы: #31, #36, #87, #239

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

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

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

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ообщить модератору
Родитель: #24 Ответы: #46, #48, #92

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

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

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

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

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

40. Сообщение от ананим.orig (?), 06-Янв-20, 12:01	+1 +/–
> И только разработчики с 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ообщить модератору
Родитель: #18 Ответы: #53

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

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. В линуксе вот этот момент гораздо правильней реализован
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #61

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

61. Сообщение от Аноним (26), 06-Янв-20, 13:10	+4 +/–
Угу. Процитирую эту статью: > 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ообщить модератору
Родитель: #42 Ответы: #69, #81

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

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

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

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

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

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

69. Сообщение от Аноним (6), 06-Янв-20, 13:40	+1 +/–
> Угу. Процитирую эту статью: >> 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ообщить модератору
Родитель: #61 Ответы: #103

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

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

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

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

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

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

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

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

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

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

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

82. Сообщение от rvm1975 (?), 06-Янв-20, 14:04	+/–
в php коде ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

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

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

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

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

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

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

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

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

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, во второй чья-то жежешечка, для просмотра которой надо иметь учётку в ЖЖ, потому что просмотр только залогиненным лжеюзерам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #118

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

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

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

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

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

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

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

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

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

103. Сообщение от Аноним (26), 06-Янв-20, 14:49	+1 +/–
Люблю когда по делу переписка. По первому куску кода 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ообщить модератору
Родитель: #69 Ответы: #136, #173

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

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

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

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

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

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

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

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

114. Сообщение от Michael Shigorin (ok), 06-Янв-20, 15:09	+11 +/–
Ага.  Мне особенно приглянулись вот эти кусочки: > 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ообщить модератору
Родитель: #93 Ответы: #157, #209, #287, #380

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

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

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

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

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

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

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

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

124. Сообщение от ананим.orig (?), 06-Янв-20, 15:21	–2 +/–
враньё
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

125. Сообщение от Аноним (26), 06-Янв-20, 15:23	+3 +/–
> про затмения на Марсе — тоже очень интересная тема. Интересная наверное тема, да. > при этом они также ничего не меняют (и не добавляют) к сабжу вообще и к содержимому ответа 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ообщить модератору
Родитель: #90

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

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

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

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

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

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

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

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

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

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

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ообщить модератору
Родитель: #103 Ответы: #170

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

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

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

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

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

142. Сообщение от Аноним (140), 06-Янв-20, 16:26	+1 +/–
В оригинальном посте автор звукового сервера 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, #167, #323, #343

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

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

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

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

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

150. Сообщение от Аноним (156), 06-Янв-20, 17:03	+1 +/–
Лол один программист стоит 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ообщить модератору
Родитель: #104 Ответы: #151, #187

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

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

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ообщить модератору
Родитель: #144 Ответы: #162, #213

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

155. Сообщение от Аноним (182), 06-Янв-20, 17:08	+/–
Наполеон ответил http://www.inpearls.ru/146075
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #160, #165

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

157. Сообщение от Аноним (157), 06-Янв-20, 17:12	+3 +/–
Уже)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ообщить модератору
Родитель: #170

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

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

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

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

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

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

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

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

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

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

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

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ообщить модератору
Родитель: #204 Ответы: #234

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

234. Сообщение от Ordu (ok), 06-Янв-20, 21:12	–1 +/–
>> они были до введения 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ообщить модератору
Родитель: #214 Ответы: #318

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

252. Сообщение от антонимус (?), 06-Янв-20, 22:58	+/–
Статистику в студию...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #296

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

316. Сообщение от nich (ok), 07-Янв-20, 09:03	+/–
Windows Internals 7th edition
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

317. Сообщение от Аноним (317), 07-Янв-20, 09:17	+/–
Привет тебе от Коливаса :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247

318. Сообщение от Аноним (26), 07-Янв-20, 09:18	+1 +/–
> В перекидывании потока: за ним ведь приходится тянуть все кеши. Ну, нет. Представим ситуацию. Поток 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ообщить модератору
Родитель: #234 Ответы: #328

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ообщить модератору
Родитель: #256

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

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

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

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

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

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

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

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

328. Сообщение от Ordu (ok), 07-Янв-20, 12:09	+1 +/–
>> В перекидывании потока: за ним ведь приходится тянуть все кеши. > Ну, нет. Представим ситуацию. Поток 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ообщить модератору
Родитель: #318 Ответы: #330

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

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

331. Сообщение от Аноним (341), 07-Янв-20, 12:56	+1 +/–
Я и сам раньше так думал)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #275

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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). Как это сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #357, #385

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

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

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

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

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

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

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

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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #354 Ответы: #370

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

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

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

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

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

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

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

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

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

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ообщить модератору
Родитель: #365 Ответы: #376

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

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'е, в каждом случае выбирая различные абстракции в предметной области, так и объяснять можно на разных уровнях и в разных абстракциях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358 Ответы: #374

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

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

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

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, а отношение ядер/потоков явно не в пользу ядер).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #370

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

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

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

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

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

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

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

382. Сообщение от Аноним (383), 08-Янв-20, 15:58	+/–
Нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #372

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ообщить модератору
Родитель: #388 Ответы: #413

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

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

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

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ообщить модератору
Родитель: #399 Ответы: #402

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

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

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

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ообщить модератору
Родитель: #403 Ответы: #406

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

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ообщить модератору
Родитель: #406 Ответы: #408

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ообщить модератору
Родитель: #407 Ответы: #409

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

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

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

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

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ообщить модератору
Родитель: #397

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

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

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

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

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

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