forum.opennet.ru

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

Оглавление

Линус Торвальдс опроверг проблемы с планировщиком задач, всп..., opennews (??), 06-Янв-20, (0) [смотреть все] +1

Ничего не понял из текста, но я более за Линуса гугл в утиль , Аноним (2), 10:23 , 06-Янв-20, (2) +23 //

болею извиняюсь, опечатка , Аноним (2), 10:24 , 06-Янв-20, (3) –2 //

Выздоравливай 129298 , iPony129412 (?), 11:11 , 06-Янв-20, (21) +73 //

Спасибо, только насморк остался ещё, Аноним (2), 16:49 , 06-Янв-20, (147) +4

держи лекарство от Линуса - FuckUoyNvidia png, Baz (?), 14:38 , 08-Янв-20, (379) –1

Не забудьте специально для него заточенные салфетки Клинюкс, ммнюмнюмус (?), 22:31 , 08-Янв-20, (386)

Спинлок, грубо говоря, это пустой цикл, выполняемый с целью задержки Если откры, Аноним (6), 10:43 , 06-Янв-20, (6) //

Эммм, что за херню вы принесли и какие идиоты вас плюсанули Цель спинлоков - не, Урри (?), 17:27 , 06-Янв-20, (164) +10 //

Это называется побочный эффект алгоритма А кто не принимает во внимание, что , Аноним (6), 18:13 , 06-Янв-20, (181) +1

facepalm Охохохохо Спинлок - это не тупой цикл Это давно-давно, еще когда д, Урри (?), 18:45 , 06-Янв-20, (188) +3

gt оверквотинг удален Я понимаю, что некоторые динозавры до сих пор не знают, , Аноним (6), 19:35 , 06-Янв-20, (206) +1

Стоит уточнить усугубить, что в linux в современной glibc mutex ы реализованы , erthink (ok), 18:31 , 06-Янв-20, (186) +12
ИМХО это просто костыль оставшийся от лени делать программные прерывания Асинхр, letsmac (ok), 13:06 , 07-Янв-20, (333) –2
Захваченности чего Mutex нельзя захватить Это просто сигнализирующий механизм , ПриветКолян (?), 19:27 , 09-Янв-20, (411)

Захватить это и есть вывесить вывеску на пустую дверь Кто первый тот и папа Д, КО (?), 15:22 , 13-Янв-20, (414)

Ага, ну да, конечно, у Штадии проблемы из-за плохого планировщика в линуксе, а с, vitalif (ok), 14:21 , 06-Янв-20, (91) +12
Из такого вольного пересказа Я бы тоже ничего не понял Читайте ответ Линуса в о, Аноним (93), 14:22 , 06-Янв-20, (93) +5 //

Ага Мне особенно приглянулись вот эти кусочки Прям почти старый добрый Линус , Michael Shigorin (ok), 15:09 , 06-Янв-20, (114) +11 //

Уже , Аноним (157), 17:12 , 06-Янв-20, (157) +3
В руководстве американских корпораций сплошные Лингамапутры с цыганскими методам, Аноним (209), 19:42 , 06-Янв-20, (209) –1
На скольких и на каких , axredneck (?), 00:22 , 07-Янв-20, (287) –1
Старый Суровый Линус, я бы сказал , InuYasha (?), 14:48 , 08-Янв-20, (380)

не понял - не пиши сюда , Аноним (140), 16:25 , 06-Янв-20, (140) +3
Вы просто неправильно их используете , Аноним (207), 19:37 , 06-Янв-20, (207)
всё очевидно же очередной смyзихлёб в зауженных тениках прострелил себе ногу н, заминированный тапок (?), 12:15 , 07-Янв-20, (329) –1
Я ничего не понял, но я за Торвальдса Кичишься своим невежеством, и ещё 50 с, Аноним (348), 17:48 , 07-Янв-20, (348) +1 //

а чего ж ссылки то не дали , JL2001 (ok), 21:15 , 07-Янв-20, (359)

А что тут непонятного-то Разработчики игр и околоигровая братия считают, что Ли, Kuromi (ok), 23:28 , 08-Янв-20, (387)
Мужик Я нихера не понял, что ты сказал мне, но ты мне близок Ты заговорил, и дос, Тот_Самый_Анонимус (?), 06:22 , 09-Янв-20, (393) +2

Линус Торвальдс опустил диванного эксперта, Нанобот (ok), 10:24 , 06-Янв-20, (4) +7 //

Линусу или пора опять в отпуск, подумать над своим поведением , или он обратно о, Аноним (25), 11:20 , 06-Янв-20, (25) –26 //

Линусу повезло, что эксперт не трансвестит или что-то вроде , Аноним_t (?), 11:41 , 06-Янв-20, (32) +30 //

Захочет отомстить 8212 сменит Gamergate v2 0 пока что не исключён , Аноним (109), 15:03 , 06-Янв-20, (109) +1
Ой ли , ПриветКолян (?), 19:31 , 09-Янв-20, (412)

Реально жесть Смотреть до конца , Аноним (38), 11:56 , 06-Янв-20, (38) +2
Как будто игроиндустрии бывают какие-то другие , Аноним (94), 14:24 , 06-Янв-20, (94) +1

Скрыто модератором, Аноним (5), 10:29 , 06-Янв-20, (5) –12 //

Скрыто модератором, Анонимышь (?), 11:16 , 06-Янв-20, (22) +11
Скрыто модератором, Аноним (348), 17:51 , 07-Янв-20, (349) +1

Хм, неожиданно Много лет использую spin lock-и в местах, где lock очень коротки, anonymous (??), 10:46 , 06-Янв-20, (7) +2 //

Важная деталь использовать с большой осторожностью и полностью разбираясь в дет, Аноним (6), 10:50 , 06-Янв-20, (10) +8 //

Если быть конкретнее, то Линус говорит То есть с его точки зрения, я всё это вре, anonymous (??), 11:32 , 06-Янв-20, (29) +4 //

Из-за этого редко некоторые игры на Stadia лагают, поэтому Линус ему так и ответ, anonymous (??), 11:41 , 06-Янв-20, (31) +6

а разве мерил разработчик стадии там вроде какой-то левый чувак вобще , колба (?), 14:18 , 06-Янв-20, (88) +1

Не так что бы всё Точнее можно оценить из соотношения времён взятия спинлока и , Аноним (6), 11:53 , 06-Янв-20, (36) +5

Ой да Единственно что дополню по упорным типа меня лучше работало сунешь пал, Michael Shigorin (ok), 15:14 , 06-Янв-20, (120)

Миша, ты на праздниках перебрал, что-ли Уносит тебя куда-то не туда , Аноним (190), 18:51 , 06-Янв-20, (190) +1

Иду я и вижу человек дотронулся до трансформаторной будки, его бьёт током Среа, Аноним (6), 08:06 , 07-Янв-20, (312) +5

А я сунул Точнее за оголенные провода специально взялся Нехило так потом руку , Cadet (?), 19:00 , 13-Янв-20, (417)

это говорит о том что вы не до конца понимаете как работает спинлок, но вам пове, колба (?), 14:16 , 06-Янв-20, (87)
Правильный быстрый lock должен быть как критические секции в винде В случае про, Аноним (239), 21:40 , 06-Янв-20, (239)

Вы просто неправильно их используете , Аноним (207), 19:39 , 06-Янв-20, (208)

На коротких спинлоках статистически ты выигрываешь Но изредка возможны относит, Аноним_t (?), 11:45 , 06-Янв-20, (35) +13
А ещё он говорил что обычный юзер имеет право менять системное время на хосте , псевдонимус (?), 12:51 , 06-Янв-20, (57)
в php коде , rvm1975 (?), 14:04 , 06-Янв-20, (82)
Имхо костыль Что конкретно Вы этим костыляете - сказать затрудняюсь, но я бы не, Egan (?), 15:06 , 06-Янв-20, (112)
Тогда на всякий напомню его же подобное по стилю разъяснение о том, почему PAE и, Michael Shigorin (ok), 15:11 , 06-Янв-20, (117) +1 //

Эта статья вызывает мегатонны фейспалмов и показывает, что бестолковость Торваль, Anonymoustus (ok), 17:18 , 06-Янв-20, (161) +3
А разве где-то память через PAE реально использовалась Самый реальный пример ко, Kuromi (ok), 23:38 , 08-Янв-20, (389) //

В том же Oracle RDBMS в стародавние времена в качестве кеша И прочих программа, КО (?), 10:22 , 09-Янв-20, (396)

Строго говоря, Линус говорит, что их ненужно использовать, если вы точно не знае, Аноним (195), 18:58 , 06-Янв-20, (195)
This У него прирост производительности aka Average test duration на спинлок, Сергей (??), 18:07 , 07-Янв-20, (351) +1 //

Если чувака интересует только задержка, что из переписки не очевидно, то он явно, Forth (ok), 20:46 , 07-Янв-20, (356) //

А всякие starvation и проблемы с перегруженным процессором его не колеблют, то , КО (?), 10:27 , 09-Янв-20, (398)

Вообще-то он про другое говорит В основном про методику измерения времени задер, КО (?), 15:25 , 13-Янв-20, (415)

Если на MuQSS не будет провала а я подозреваю что это так , то прав совсем не Л, Аноним (8), 10:47 , 06-Янв-20, (8) +2 //

По такой же логике можно обвинить компилятор, если программа не работает, когда , anonymous (??), 11:17 , 06-Янв-20, (23) +3 //

Челюсть ставишь, что без спинлоков на CFS будет быстрее Или просто так ляпнул, , Аноним (8), 12:48 , 06-Янв-20, (56) –5 //

Это ты челюсть поставил вот этой заявой и предположениям выше про MuQSS Так что, Аноним (6), 13:53 , 06-Янв-20, (78) +2

Поздравляю, Шарик, ты балбес Иди чекни статью по оп ссылке, Аноним (8), 14:48 , 06-Янв-20, (101) –4

Тебе надо, ты и иди Заодно челюсть спасёшь , Аноним (6), 15:14 , 06-Янв-20, (119) +1

Я предпочитаю просто обсуждать вопрос в плоскости логики и или ссылок на факты , anonymous (??), 11:07 , 07-Янв-20, (325)

Тут сразу вспоминается история с memcpy , glibc и adobe flash, Аноним (231), 21:01 , 06-Янв-20, (231) +2 //

а что там было , JL2001 (ok), 00:03 , 08-Янв-20, (364)

я так понимаю, имеется в виду вот это https www linux org ru news linux-gener, Совершенно другой аноним (?), 09:27 , 09-Янв-20, (395) +1

Сложно сказать, как в этом случае Возможно в данном случае Линус прав не поним, Совершенно другой аноним (?), 09:26 , 09-Янв-20, (394)

Нет В тот раз проблема была в навязывании всем Есть дураки, которые не понима, nobody (??), 13:29 , 09-Янв-20, (399)

Ну так, к сожалению, Линус такое и предлагает в https bugzilla redhat com show, Совершенно другой аноним (?), 15:15 , 09-Янв-20, (401)

А я что написал , nobody (??), 15:20 , 09-Янв-20, (402)

Прошу прощения, значит я неправильно понял Ваш посыл , Совершенно другой аноним (?), 15:39 , 09-Янв-20, (404)

Прошу прощения за свою лень, напишу, не смотря в исходники В упомянутых функция, Аноним (6), 15:33 , 09-Янв-20, (403)

простая, но оптимизированная для x86, memcpy выглядит так ------------------X, Совершенно другой аноним (?), 15:49 , 09-Янв-20, (405)

I d personally suggest that glibc just alias memcpy to memmove В glibc она, Аноним (6), 16:09 , 09-Янв-20, (406)

Не могу с Вами, как и с Линусом, согласиться На малых и известных на этапе комп, Совершенно другой аноним (?), 16:22 , 09-Янв-20, (407)

Тоже наблюдал такое и очень давно Именно это и имел ввиду, когда писал что сама, Аноним (6), 16:35 , 09-Янв-20, (408)

Тоже думал про такой аспект, но забыл написать , Совершенно другой аноним (?), 16:49 , 09-Янв-20, (409)

Независимо от результатов с muqss, это не противоречит словам Линуса, просто пот, Аноним (41), 12:04 , 06-Янв-20, (41) //

Где-то тут должна была быть логика, но она не обнаружена Зачем мне планировщик,, Аноним (8), 12:47 , 06-Янв-20, (55) +2 //

а кто сказал что он не оптимизирован зыжи да 8212 кто не обнаружил логику , ананим.orig (?), 14:05 , 06-Янв-20, (83) +1

Он переоптимизирован настолько сильно, что стал работать медленнее Ок, Аноним (8), 14:49 , 06-Янв-20, (105) +1

враньё, ананим.orig (?), 15:21 , 06-Янв-20, (124) –2

Поддерживаю В чем смысл одного универсального, но менее эффективного планировщи, Аноним (133), 15:41 , 06-Янв-20, (133) +3

А какие ОС нынче имеют несколько специализированных планировщиков, не просветите, Аноним (109), 20:23 , 06-Янв-20, (217) +1

Не хочу вас расстраивать, но под персонально ваши задачи не будут оптимизировать, Аноним (109), 20:26 , 06-Янв-20, (220)
А ты забавный Понтов дофига и прям все тебе должны Мы тебя прощаем, пакуйся с , антонимус (?), 21:31 , 06-Янв-20, (237)

Виндовый планировщик прекрасно отрабатывает как в серверной, так и в десктопной , zzz (??), 14:19 , 06-Янв-20, (89) –12 //

И тут же все вместе, включая набрасывающего на вентилятор, тут же отправились в , ананим.orig (?), 14:26 , 06-Янв-20, (95) –2

И что top500 Там серверная аль десктопная нагрузка , zzz (??), 14:51 , 06-Янв-20, (106) –4

Там ещё более другая, скорее пакетная Ну, если учонные опять не этсамое , Michael Shigorin (ok), 15:18 , 06-Янв-20, (122)
т е наполовину ты уже соврал теперь хочешь чтобы поймали и на второй А знаешь п, ананим.orig (?), 15:25 , 06-Янв-20, (128) –1

Алкоголь - зло , zzz (??), 18:19 , 06-Янв-20, (183)

Это тот, который в idle грузит все ядра на 30-50 Спасибо, ешьте сами , Аноним (109), 15:05 , 06-Янв-20, (111) +2

Скрыто модератором, Аноним (9), 10:49 , 06-Янв-20, (9) +2 //

Скрыто модератором, ыфвыфв (?), 10:56 , 06-Янв-20, (14) //

Скрыто модератором, anonymous (??), 11:19 , 06-Янв-20, (24) +3 //

Скрыто модератором, Аноним (5), 11:44 , 06-Янв-20, (33)

Скрыто модератором, Аноним (5), 12:14 , 06-Янв-20, (46) +12

Скрыто модератором, Аноним (60), 13:05 , 06-Янв-20, (60)

Скрыто модератором, zzz (??), 14:28 , 06-Янв-20, (96) +2

Скрыто модератором, Аноним (109), 15:10 , 06-Янв-20, (115)

Скрыто модератором, Аноним (60), 15:45 , 06-Янв-20, (134) +1

Скрыто модератором, Аноним (-), 17:03 , 06-Янв-20, (148)

Скрыто модератором, Аноним (109), 20:59 , 06-Янв-20, (230)

Скрыто модератором, Аноним (109), 20:29 , 06-Янв-20, (221)

Скрыто модератором, Евгений (??), 05:31 , 07-Янв-20, (305)

Скрыто модератором, zzz (??), 18:29 , 06-Янв-20, (185) +2

Скрыто модератором, Аноним (109), 20:33 , 06-Янв-20, (222)

Скрыто модератором, Аноним (109), 20:39 , 06-Янв-20, (223) +1

Скрыто модератором, Аноним (6), 08:35 , 07-Янв-20, (314)

Скрыто модератором, zzz (??), 01:15 , 07-Янв-20, (293) +1

Скрыто модератором, Аноним (109), 21:07 , 06-Янв-20, (233)

Скрыто модератором, runoverheads (ok), 16:26 , 06-Янв-20, (141) +1

Скрыто модератором, Аноним (158), 17:13 , 06-Янв-20, (158) +1
Скрыто модератором, Аноним (158), 17:17 , 06-Янв-20, (159) +1

Скрыто модератором, drTrue (?), 19:04 , 06-Янв-20, (197)

Скрыто модератором, drTrue (?), 19:08 , 06-Янв-20, (198) +1

Скрыто модератором, Аноним (215), 20:08 , 06-Янв-20, (215)

Скрыто модератором, анонн (ok), 20:54 , 06-Янв-20, (227) +3

Скрыто модератором, Аноним (215), 22:47 , 06-Янв-20, (250)

Скрыто модератором, Аноним (109), 20:57 , 06-Янв-20, (228) –3

Скрыто модератором, Аноним (109), 21:02 , 06-Янв-20, (232)

Скрыто модератором, Ordu (ok), 12:19 , 06-Янв-20, (48) +2

Скрыто модератором, Аноним (5), 12:27 , 06-Янв-20, (52)

Скрыто модератором, Ordu (ok), 13:44 , 06-Янв-20, (70) +1
Скрыто модератором, Аноним (109), 15:15 , 06-Янв-20, (121) –3

Скрыто модератором, Аноним (94), 14:22 , 06-Янв-20, (92)

Скрыто модератором, Аноним (109), 15:13 , 06-Янв-20, (118)

Скрыто модератором, Аноним (140), 16:24 , 06-Янв-20, (139) //

Скрыто модератором, drTrue (?), 19:10 , 06-Янв-20, (199)

Скрыто модератором, Аноним (79), 13:57 , 06-Янв-20, (79) +3

вантузный игродел решил попрграмировать под линукс и публично опозорился, Аноним (11), 10:52 , 06-Янв-20, (11)
ахахаха, спорить с родителем самой linux-системылучше бы он этого не делал, Аноним (11), 10:54 , 06-Янв-20, (12) –6 //

Автором планировщика для ядра Linux что самого первого O 1 , что второго, CFS , Аноним (5), 10:59 , 06-Янв-20, (15) +3 //

Другое дело, оффтопик Вызвал timeBeginPeriod и всё стало плавно Правда, в до, Аноним (6), 11:04 , 06-Янв-20, (17) –1
И только разработчики с 10 лет стажа сейчас тяжело вздохнули ибо знают, что сит, llol (?), 11:08 , 06-Янв-20, (18) +7 //

ибо знают cfs шедулер это про Фому, а cfq шедулер 8212 про Ерёмупервый 8212, ананим.orig (?), 12:01 , 06-Янв-20, (40) +1

https www linux org ru news linux-general 2042898 cid 2045250, Аноним (5), 12:35 , 06-Янв-20, (53)

есть планировщик задач, а есть планировщик ввода-вывода во-о-о-т наводящий воп, ананим.orig (?), 11:37 , 06-Янв-20, (30) +5
баг 12309 вызван проблемами в чипсете intel вышедшем в то время, на amd как вы м, Аноним (306), 06:04 , 07-Янв-20, (306)

Почему же лучше Человек, в результате, получил обратную связь от Торвальдса Ес, Ordu (ok), 12:26 , 06-Янв-20, (51) +12
А что, спорить с ним нельзя Можешьне отвечать, я уже понял что ты сектант , псевдонимус (?), 13:00 , 06-Янв-20, (59) –3 //

Нет Не потому что Линус прав, а потому что спорить с ним нельзя О том и новост, Аноним (79), 13:59 , 06-Янв-20, (80) –2 //

Ещё один чукча-писатель Новость о том, что блокировки -- это сложно И с кондач, Michael Shigorin (ok), 15:23 , 06-Янв-20, (126) +3

Еще можно придумать заголовок что у Линуса новая должность капитан очевидность , Аноним (156), 17:11 , 06-Янв-20, (156) –1

Не стоит спорить с людьми, которые умнее и грамотнее тебя в предметной области , Аноним (109), 15:19 , 06-Янв-20, (123) //

А вот разговаривать -- стоит Скорее с почему и зачем , по опыту , Michael Shigorin (ok), 15:24 , 06-Янв-20, (127) +5
От того что Линус грамотнее меня в своей предметной области игрушка шустрее рабо, псевдонимус (?), 15:50 , 06-Янв-20, (135) –1

В общем виде Игроделы заточились под вынь Тупой порт на другие платформы дает т, Аноним (157), 17:36 , 06-Янв-20, (169) +3

Претензия ко второй платформе проста она пытается уметь все А когда указывт на , псевдонимус (?), 17:55 , 06-Янв-20, (177) –3

А ненадо всё валить в кучу, планировшик и vm это разные вещи , Аноним (306), 06:06 , 07-Янв-20, (307)

Вот и не надо мешать задачи сервака, суперкомпа и десктопа, прикрываясь фиговым , псевдонимус (?), 20:27 , 07-Янв-20, (355)

Вторая платформа если уж решила быть комбайном могла бы подумать про качество ра, Аноним (156), 20:44 , 06-Янв-20, (225)
В таком случае они бы использовали критические секции, а не велосипед Когда они , Аноним (6), 08:47 , 07-Янв-20, (315)

Ну Windows спасет только мощное железоА даже на старом хламе вполне норм линукс , Аноним (254), 23:01 , 06-Янв-20, (254) +2

А как тогда вытащить из них то, чем они умнее и грамотнее Иного приходится прив, Аноним (94), 16:16 , 06-Янв-20, (138) +3

Методика паразита Учиться не пробовал Помогает , антонимус (?), 23:45 , 06-Янв-20, (270)

Кон Коливас смотрит на эту дискуссию, как на битву нанайских мальчиков, Аноним (19), 11:08 , 06-Янв-20, (19) +6 //

http ck-hack blogspot com 2020 01 happy-new-decade html, Аноним (86), 14:11 , 06-Янв-20, (86) +4
MuQSS support cgroups, but not all the cgroup features e g CPU limiting will n, антонимус (?), 21:16 , 06-Янв-20, (236)

Забавно читать про более простые планировщики Знания внутренностей ядра Windo, Аноним (26), 11:21 , 06-Янв-20, (26) +5 //

Где почитать более свежие исходники ядра Windows Дайте адрес на GitHub, Аноним (8), 11:45 , 06-Янв-20, (34) //

Нигде Проприетарщина Тут Linux впереди планеты всей Лишь бы работал хорошо И, Аноним (26), 11:54 , 06-Янв-20, (37) +1 //

ну и нафига тогда этот спич выше про вантуз, если сабж 8212 цитата очевидно , ананим.orig (?), 12:10 , 06-Янв-20, (44) +1

Спич про Windows к содержимому ответа Linus а, и некоторой части коментаторов в , Аноним (26), 13:18 , 06-Янв-20, (65) +1

про затмения на Марсе 8212 тоже очень интересная тема при этом они также ниче, ананим.orig (?), 14:19 , 06-Янв-20, (90) –1

Интересная наверное тема, да Как по мне, так это Linus про планировщик Windows , Аноним (26), 15:23 , 06-Янв-20, (125) +3

M предоставляет исходники своей продукции включая Windows всех версий в ФСБ, ин, drTrue (?), 19:16 , 06-Янв-20, (200) +1 //

МС предоставляет бабки, а не исходники Кстати,Неправда Сертификация ФСТЭК нужна, Аноним (109), 21:12 , 06-Янв-20, (235) +1

Нет, для закупок винды в госучреждения код винды должен был быть предоставлен ФС, drTrue (?), 22:01 , 06-Янв-20, (242)

И гугл как раз скажет, что сертификаты нужны для аттестации, а аттестовать нужно, anonymous (??), 11:05 , 07-Янв-20, (324)

Windows Internals 7th edition, nich (ok), 09:03 , 07-Янв-20, (316)

https www techpowerup com review 1usmus-custom-power-plan-for-ryzen-3000-zen-2, Аноним (42), 12:04 , 06-Янв-20, (42) //

Угу Процитирую эту статью Ну, во первых, термина busy в планировщике Windows , Аноним (26), 13:10 , 06-Янв-20, (61) +4 //

Ну как бы ядро т е исполнитель и тред контекст исполнения, в т ч адрес испо, Аноним (6), 13:40 , 06-Янв-20, (69) +1

Люблю когда по делу переписка По первому куску кода WRK Не знаю, зачем сюда уже , Аноним (26), 14:49 , 06-Янв-20, (103) +1

Э, нет, дружище, я тут не весть какой помощник Мне это было интересно, когда со, Аноним (6), 16:06 , 06-Янв-20, (136)

Вероятнее всего Вопрос - понимает ли автор, что стоит за этим словом Да, занятн, Аноним (26), 17:39 , 06-Янв-20, (170)

Он относит busy к ядру процессора, которое в принципе не может быть idle но мож, Аноним (6), 19:19 , 06-Янв-20, (202)

Ну и что там внутри, мой анонимный брат , Anonymoustus (ok), 17:46 , 06-Янв-20, (173)

Гора неочевидного кода, твой анонимный брат Неочевидного - потому что ты не зна, Аноним (26), 17:54 , 06-Янв-20, (176)

Ох уж эти индусы 8230 171 Это свобода 187 8212 говорили они нам лет око, Anonymoustus (ok), 19:54 , 06-Янв-20, (212)

Хочу уточнить твои придирки, как я понял, относятся не к фактической части, а к, Ordu (ok), 14:00 , 06-Янв-20, (81)

Я утверждаю, что их нет до введения Cache Aware Scheduling пару недель назад М, Аноним (26), 15:28 , 06-Янв-20, (129)

В смысле, они были до введения Cache Aware Scheduling пару недель назад, я прави, Ordu (ok), 17:03 , 06-Янв-20, (149)

Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений, вывест, Аноним (26), 17:59 , 06-Янв-20, (178)

Где это такое видано чтобы оба сабжевых оратора были не правы Либо черное либо , Аноним (156), 18:55 , 06-Янв-20, (194)
Как можно писать, что я читаю одно твоё сообщение за другим, и до сих пор продол, Ordu (ok), 19:23 , 06-Янв-20, (204)

Поток перепрыгивает с ядра на ядро не по причине планировщик неоправданно пе, Аноним (26), 19:56 , 06-Янв-20, (214)

В перекидывании потока за ним ведь приходится тянуть все кеши Какая разница пл, Ordu (ok), 21:12 , 06-Янв-20, (234) –1

Ну, нет Представим ситуацию Поток A всегда выполнялся на ядре 0 Его квант ист, Аноним (26), 09:18 , 07-Янв-20, (318) +1

С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 проста, Ordu (ok), 12:09 , 07-Янв-20, (328) +1
С какого полового члена взято что они простаивают Из сценария из статьи, точн, Аноним (26), 12:55 , 07-Янв-20, (330)
Посмотри внимательно на график Там две кривые прыгают вверх-вниз -- это два ядр, Ordu (ok), 13:18 , 07-Янв-20, (335) –1
В этой статье нет даже объяснения, что этот график изображает Single-threaded , Аноним (26), 15:26 , 07-Янв-20, (345) +1
У меня не возникло проблем понять этот график Автор сделал открыл какую-то тулз, Ordu (ok), 20:04 , 07-Янв-20, (354)
Я уже начинаю уставать от этого диалога, если честно Я не говорю, что автор граф, Аноним (26), 21:09 , 07-Янв-20, (358)
Да, тогда когда занятых работой потоков больше чем ядер Когда их меньше, получа, Ordu (ok), 02:06 , 08-Янв-20, (370)
Это практически всегда так На моём домашнем десктопе с 6 логическими ядрами, да, Аноним (26), 10:55 , 08-Янв-20, (374)

А что, в тех сорцах есть планировщик , Аноним (6), 12:05 , 06-Янв-20, (43) //

Без понятия Если не там, то вероятно в Windows Research Kernel есть Там и исхо, Аноним (26), 13:12 , 06-Янв-20, (62)

Марк, это ты , segesg (?), 12:14 , 06-Янв-20, (47) +1
технически у виндовс нет универсального планировщика который создан с учётом и с, колба (?), 14:29 , 06-Янв-20, (97) +1 //

Технически, у Windows только универсальный и есть Код Windows клиентских и серв, Аноним (26), 15:01 , 06-Янв-20, (108)

Можно что угодно говорить про преимуществах ядра винды, но если нельзя убедиться, Аноним (146), 16:42 , 06-Янв-20, (146) //

Любой код можно расковырять, нужно лишь быть достаточно любопытным и имеющим вр, Аноним (26), 17:04 , 06-Янв-20, (152)

Я понятия не имею, что там в windows не интересует вопрос , но крутить в юзерсп, Аноним (231), 20:51 , 06-Янв-20, (226) +1 //

Там дело еще осложняется тем, что код исполняется в виртуалке , Аноним (299), 03:24 , 07-Янв-20, (299) //

Ха, ну это вообще тогда чувак измерял громкость жужжания комара, стоя рядом с ра, Аноним (231), 02:29 , 09-Янв-20, (392)

И все меньше винды оставалось на top500 Это факт, а факт - самая упрямая вещь н, антонимус (?), 20:59 , 06-Янв-20, (229) //

У нас каждый первый комментатор опеннета похоже на топ500 работает , Аноним (249), 22:42 , 06-Янв-20, (249) +1 //

Статистику в студию , антонимус (?), 22:58 , 06-Янв-20, (252)

На что статистику Как мой саркастический комментарий по поводу 500 компьютеров , Аноним (249), 02:52 , 07-Янв-20, (296)

Поражают воображение легенды и мифы опоздавших родиться мамкиных погромиздов , Anonymoustus (ok), 00:21 , 07-Янв-20, (286) +2
Благодаря таким комментариям начинаешь забывать, что у Linux есть другие, более , Аноним (26), 09:43 , 07-Янв-20, (321)

Js другое хипстерское убожество на Винде настолько тормознуто что линукс встроил, Аноним (254), 23:06 , 06-Янв-20, (256) //

Справедливости ради, node js на Windows тормозит не из-за сетевого стэка либо пл, Аноним (26), 09:29 , 07-Янв-20, (319)

Линус прав в том что спинлоки надо уметь Скорее всего автор теста не читалhttps, segesg (?), 12:10 , 06-Янв-20, (45) +1 //

Статью не читай сразу отвечай Всё там правильно сделано Опозорился тут как ра, Аноним (263), 23:29 , 06-Янв-20, (263) –3
Да это прямо в документации написано http man7 org linux man-pages man3 pthrea, Аноним (306), 06:09 , 07-Янв-20, (308)

Для игр вообще должны применяться системы без многозадачности Или с вытесняющей, Аноним (49), 12:20 , 06-Янв-20, (49) –1
Линус же указал страждущему правильный путь Есть же планировщик реального врем, Forth (ok), 13:17 , 06-Янв-20, (64) +3 //

я в целом изначально удивлён что на стадии не риалтайм использовали, но думаю ин, колба (?), 14:32 , 06-Янв-20, (98) –2 //

Да пусть сначала гуглоиндусы все свои сервисы и приложения нормально сделают, а , paulus (ok), 03:20 , 07-Янв-20, (298)
Думаю Стадию закроют в 2021-2022 году - , Аноним (371), 06:30 , 08-Янв-20, (371)

Занятно, Линус обвиняет другого разработчика в некомпетентности, при этом сам по, Аноним (66), 13:19 , 06-Янв-20, (66) +3 //

Предположу что делать кастомную систему под каждую задачу ДОРАГА Есть же систем, Аноним (79), 13:45 , 06-Янв-20, (72) +1 //

Ну, стоит заметить, что север и десктоп очень разные и широко распространённые з, Аноним (137), 16:15 , 06-Янв-20, (137) +2 //

Погоди-ка под десктоп линукс вроде особо и не заточен судя по перекосу в распрос, Аноним (156), 17:07 , 06-Янв-20, (154)

Не десктоп а клиент И да, на линуксе десятки миллионов если не больше клиентов , Аноним (137), 18:08 , 06-Янв-20, (179) +1

в таком случае это уже десятки миллиардов, не , Аноним (158), 20:24 , 06-Янв-20, (218)

Разве AFAIK, компилятор один, отличаются только дефолтные настройки типа продол, Аноним (304), 04:46 , 07-Янв-20, (304)

ага ты его раскусилудали линукс и пользуйся windows 10,только не забуть проапгре, Аноним (11), 23:46 , 06-Янв-20, (271)
Если тебе что-то не подходит то это не значит что оно гавно , Аноним (306), 06:10 , 07-Янв-20, (309)

Это финиш Как не странно, в конечном счёте важно общее время выполнения - отзыв, Аноним (66), 13:29 , 06-Янв-20, (67) –2 //

Наберите в поисковике система реального времени , ознакомьтесь с определением -, Аноним (6), 13:44 , 06-Янв-20, (71) –2 //

Можно и линукс с реалтайм ядром запускать, но есть минусы- Приложения реальног, Аноним (79), 13:49 , 06-Янв-20, (74) //

Правомерны ли исходные претензии к не реалтайм системе , Аноним (6), 14:09 , 06-Янв-20, (85)
Это если нужен hard-realtime Для soft-realtime хватит и обычного preempt_rt Я н, Forth (ok), 14:45 , 06-Янв-20, (100) +3

Soft-realtime 8212 это маркетинговое изобретение микрософта Либо система гара, Аноним (19), 21:57 , 06-Янв-20, (241) –3

Разница есть Системы hard realtime ничего и никогда не должны пропускать Потом, Forth (ok), 23:34 , 06-Янв-20, (265)

ОС общего назначения никогда не применяют в критических системах, связанных с жи, антонимус (?), 00:04 , 07-Янв-20, (280) –3

О том и речь Hard-realtime это специально спроектированные системы, способные э, Forth (ok), 09:46 , 07-Янв-20, (322)

Лучше бы ты в lklm патчи присылал Ты же обладаешь сакральным знанием , антонимус (?), 00:12 , 07-Янв-20, (284) +1
Если оно правильно измерено А если в одном случае в измеренное время паузу от в, КО (?), 15:28 , 13-Янв-20, (416)

Линус - в своём репертуаре Начиная со своего знаменитого спора с Таненбаумом А в, Аноним (68), 13:35 , 06-Янв-20, (68) +2 //

И над этим всем великолепием зависла IRS таймера, переключающая контексты , Аноним (6), 13:47 , 06-Янв-20, (73)
Тот-то Столлман так Гурд и не дописал А все потому что это ваше микроядро тупо , Аноним (79), 13:51 , 06-Янв-20, (76) +2 //

Линукс крутится - грубо, на 10 млн серверов Это 20 млн процессоров, это 1000 к, zzz (??), 14:49 , 06-Янв-20, (104) //

Лол один программист стоит 100 000 в год Для примера за 60000 можно купить во, Аноним (156), 17:03 , 06-Янв-20, (150) +1

https www amazon com Supermicro-F618R2-RT-Bay-Motherboard-E5-2697A dp B07ZTXLL, Аноним (156), 17:04 , 06-Янв-20, (151)

Глупость какая-то Куча металлолома 2 х 14 Тб HDD Toshiba в зеркале раз в 10 де, Аноним (182), 18:18 , 06-Янв-20, (182)

Если на разработку планировщика о 3 тыс строк столько весит ULE требуется отде, zzz (??), 18:40 , 06-Янв-20, (187) +4

Этим и отличается суровый энтерпрайз от поделок Васяна Васян может и напишет 30, Аноним (156), 18:51 , 06-Янв-20, (191)
Уже написанный launchd когда внедрите Или трех подходов оказалось недостаточно , Аноним (299), 03:33 , 07-Янв-20, (300) –2

Начался юлеж И да, опеннетчики, по причине ношения маечки с пингвинчиком и устан, Аноним (352), 19:20 , 07-Янв-20, (352)

При том, что эти сервера крутят в солидном случаев скриптоту, претензия к неоп, Сишник (?), 19:30 , 06-Янв-20, (205) +1

Это именно то, чего вы хотели, чего теперь плакаться А с другой стороны - что, , zzz (??), 23:09 , 06-Янв-20, (257)

Но забавляет вера неофитов, что лютая махровая проприетарщина, каковой ещё с кон, Anonymoustus (ok), 00:26 , 07-Янв-20, (288) +1

Если ты наивен, не думай, что все такие-же https www linuxfoundation org membe, антонимус (?), 00:57 , 07-Янв-20, (291)

И да, по исходникам таки работает GPL Есличо , антонимус (?), 01:02 , 07-Янв-20, (292)

Работают, работают Только толку от GPL, если в апстрим никто ничего впилить не , zzz (??), 01:22 , 07-Янв-20, (294)

Кто виноват и что делать - вечный вопрос А толку от GPL - закрыть можно не всё, антонимус (?), 02:25 , 07-Янв-20, (295)

И в линуксе - тоже фиг поменяешь , zzz (??), 03:37 , 07-Янв-20, (302)

Только вот в современных облачных реалиях все что не AGPL - подарок корпоративны, анонн. (?), 19:29 , 07-Янв-20, (353) +1

Зато гугл взял и написал И дрова будут Одно дело какие-то nicheброды без денег, Аноним (110), 15:05 , 06-Янв-20, (110) –3 //

Зуб даёте По-моему - план приписан а по себе людей не судят - лучше быть ни, Michael Shigorin (ok), 15:34 , 06-Янв-20, (132) +4
1 Купил и дописал 2 Дров не будет , антонимус (?), 22:11 , 06-Янв-20, (245)

Не с того начали Железо какое , Michael Shigorin (ok), 15:32 , 06-Янв-20, (130) +1
Почитай ради интереса про стоимость переключения контекста на x86 Просто чтобы , антонимус (?), 21:54 , 06-Янв-20, (240) //

И чтобы два раза не вставать, в SPARC совсем другая ситуация Была, к сожалению,, антонимус (?), 22:07 , 06-Янв-20, (243)

С микроядрами все хорошо только на бумаге По факту же, как только все сводится к, Аноним (231), 02:27 , 09-Янв-20, (391)

Так может, так и надо делать провести специфичную оптимизацию, вынести её в отд, Annoynymous (ok), 13:50 , 06-Янв-20, (75) +2 //

Google Stadia 8212 это и есть сервера к тому же вам уже скомпилировали вантуз, ананим.orig (?), 14:35 , 06-Янв-20, (99)
А может лучше игроделы под google stadia пусть научаться в spinlock Или использу, Аноним (157), 17:21 , 06-Янв-20, (163) //

171 Stadia предлагает мгновенный доступ к игре без необходимости загружать или, антонимус (?), 22:21 , 06-Янв-20, (246)

А сделал вывод, что нам не хватает планировщика, для рабочего стола , gfederix (ok), 15:32 , 06-Янв-20, (131)
В оригинальном посте автор звукового сервера JACK сказал несколько дельных вещей, Аноним (140), 16:26 , 06-Янв-20, (142) +1
Где всезнающий пох Эй, пох Ты всё знаешь, подскажи решение бытовой задачки - к, Anonymoustus (ok), 16:35 , 06-Янв-20, (144) //

https www sim-networks com wiki create-software-raid-in-windows-server, Аноним (182), 17:05 , 06-Янв-20, (153) //

Как-то слишком просто такая задача на нормальных ос требует жестких плясок в кон, Аноним (156), 17:20 , 06-Янв-20, (162) //

Недавно понадобилось Тоже удивился , Аноним (182), 17:32 , 06-Янв-20, (166)
Какие жесткие пляски, дети Одна строчка в консоли Одна, Карл , Не пох а ктото другой (?), 17:36 , 06-Янв-20, (168)

А потом на загрузке будет у тебя mduuid not found и начинаются пляски , Аноним (156), 23:01 , 06-Янв-20, (253) –1

Ты и в windows not found добьёшься, талант , Аноним (306), 06:13 , 07-Янв-20, (310)

К сожалению, да Под сервером Windows софтовый RAID без проблем конфигурируется , Аноним (182), 17:43 , 06-Янв-20, (171) +1

ты не совсем прав мы решили данную проблему главное - вредные советы из интерн, Аноним (182), 17:45 , 06-Янв-20, (172)
Вы читать умеете Человек хочет raid-1 после установки Ты тут лепишь что-то про, Не пох а ктото другой (?), 19:53 , 06-Янв-20, (211)

В Windows 2003 такой функциональности нету в оснастке , Anonymoustus (ok), 19:56 , 06-Янв-20, (213) +1

Тебе надо драйвер адаптека вручную поставить через управление компьютером устрой, Не пох а ктото другой (?), 17:33 , 06-Янв-20, (167) +1 //

Могу сказать на твой совет - он вреден хотя адаптека немного обогатит Посмотр, Аноним (182), 17:49 , 06-Янв-20, (174) //

Вреден кому Я вопрошающему ответил, что ему делать надо, как понял его же вопрос, Не пох а ктото другой (?), 19:52 , 06-Янв-20, (210)
А что, разве остались еще контроллеры, не использующие DDF , Аноним (299), 03:37 , 07-Янв-20, (301) +1

Ну раз ты такой гуру 8230 Давай-ка переформулирую Винда во время загрузки пок, Anonymoustus (ok), 17:56 , 07-Янв-20, (350) //

Мне и раньше все было понятно и проблема твоя синим по белому написана, да вот т, Не пох а ктото другой (?), 21:01 , 07-Янв-20, (357)

Винда была установлена на отдельный винт, а не на массив, поскольку не было диск, Anonymoustus (ok), 21:24 , 07-Янв-20, (361)

Еще раз, медленно мне кристально ясно что у тебя не так Если бы этот сервер бы, Не пох а ктото другой (?), 00:04 , 08-Янв-20, (365)

1 У меня SCSI, а не SATA Перепиши свои умные советы с учётом этой досадной мел, Anonymoustus (ok), 01:21 , 08-Янв-20, (368)

Я терпеливый человек, но у терпения предел есть и он заканчивается Какая разница, Не пох а ктото другой (?), 11:48 , 08-Янв-20, (376) +1

А консоль восстановления увидит диски в массиве Попробуй подумать ещё разок Не, Anonymoustus (ok), 14:18 , 08-Янв-20, (377)

Конечно увидит, если знать что делать Зачем тебе дискета Для того, чтобы консо, Не пох а ктото другой (?), 15:40 , 08-Янв-20, (381)

Мальчик, ты дурак , Anonymoustus (ok), 21:19 , 08-Янв-20, (384)

Впрочем, драйвер винде я таки подсунул Попробую собрать диски в массив и после , Anonymoustus (ok), 23:08 , 07-Янв-20, (363)

Эту даже я до сих пор помню а гугл и не забывал 0x0000007B INACCESSIBLE_BOOT_D, PnD (??), 21:30 , 08-Янв-20, (385)

Нет, синий экран у меня с другим сообщением Я уже разобрался с синим экраном В, Anonymoustus (ok), 23:32 , 08-Янв-20, (388)

0 Смотрим что есть AIC-7902 Аппаратный u320-scsi один из последних , так что , PnD (??), 10:22 , 09-Янв-20, (397)

В общем, я эту траблу победил без дискеты По пунктам 1 В адаптековском BIOS от, Anonymoustus (ok), 23:59 , 09-Янв-20, (413)

Скорее всего, я раньше куплю флопик и пачку дискет, чем дождусь дельного совета , Anonymoustus (ok), 09:56 , 07-Янв-20, (323)
Никогда не используйте софтварный RAID в Windows вне зависимости от реализации ,, Аноним (343), 14:37 , 07-Янв-20, (343) +1 //

Думаю, что ты стопроцентно прав, анонимный брат Я уже в поиске подходящего желе, Anonymoustus (ok), 17:46 , 07-Янв-20, (347) //

Это каким образом вам удалось потерять данные с зеркала Тома intel matrix rapid, Аноним (343), 11:30 , 08-Янв-20, (375)

Это отдельная история, но я счёл её малоинтересной для опеннетовского анонима В, Anonymoustus (ok), 14:24 , 08-Янв-20, (378)

В гугл стали набирать на работу клоунов, причём целыми командами , all_glory_to_the_hypnotoad (ok), 16:36 , 06-Янв-20, (145) +1 //

Наполеон ответилhttp www inpearls ru 146075, Аноним (182), 17:08 , 06-Янв-20, (155) //

А стадо баранов возглавляемое бараном И по какой методике априорно производить , Аноним (156), 17:18 , 06-Янв-20, (160)
Тут, к сожалению, стадо баранов под руководством барана против законов физики , all_glory_to_the_hypnotoad (ok), 17:28 , 06-Янв-20, (165) //

Ну почему к сожалению, физике пофиг, бараны против ейных законов или единороги , антонимус (?), 22:38 , 06-Янв-20, (248)

Еще один мудила из нижнего тагила пишет игры на ОС общего назначения Dа на мест, Аноним (175), 17:52 , 06-Янв-20, (175) //

Игры сейчас уже не те, они полагаются именно на поведение планировщиков Вон даж, Аноним (158), 18:29 , 06-Янв-20, (184)
И сразу же пойти на SO с вопросом как собрать проект Unity под DOS , Аноним (299), 03:40 , 07-Янв-20, (303)

Товральдс Мужик Поставил зарвавшегося юнца на место , Аноним (-), 18:12 , 06-Янв-20, (180) +10 //

Юнца поставил, молодец против овец Зато против рыжего гремлина и своей дочурки о, псевдонимус (?), 19:21 , 06-Янв-20, (203) +2 //

Вот здесь согласен Батя толжен быть Батей прежде всего в семье, и ставить зарва, Аноним (-), 21:34 , 06-Янв-20, (238) +5

Чииго, бл ть Вот нахрен мне это знать Из всех сервисов гугла интересны тольк, user90 (?), 18:53 , 06-Янв-20, (192) –1 //

Зря ты так Тут вообще хорошая идея в основе лежит Идея в том, что срать на чем, Аноним (175), 00:17 , 07-Янв-20, (285)
все там нормально в яндексе, whiplash (?), 11:45 , 07-Янв-20, (326)

Вот яркий пример того, что сейчас происходит и не только в гейдеве Вообще не зна, Корец (?), 18:53 , 06-Янв-20, (193) //

В будущем тебе будет не до этого, чувак, гарантирую Да даже в 2020ом , user90 (?), 18:59 , 06-Янв-20, (196)

Как будто десктоп - это что-то плохое А напаркуа мне серверные системы на дома, Аноним (244), 22:08 , 06-Янв-20, (244) +2 //

Паркуатор, вырыгай кактус и одомашнивай комп Тебе никто ничего не обещал и не д, антонимус (?), 22:27 , 06-Янв-20, (247) –1 //

Привет тебе от Коливаса , Аноним (317), 09:17 , 07-Янв-20, (317)

Один человека говорит что играть в футбол на траве гораздо удобнее в бутсах, а е, Аноним (156), 22:58 , 06-Янв-20, (251) //

Ну а что же тогда мешает играть в бутсах этому господину , Аноним (254), 23:22 , 06-Янв-20, (259) –1 //

Так он играет в бутсах в другой системе, подходит к мистерам в валенках и говори, Аноним (367), 00:32 , 08-Янв-20, (367)

А На модном го и Данте если бутсы запилить - вообще все летать будет, Аноним (254), 23:25 , 06-Янв-20, (260)
Не, ты неверно проводишь аналогию, если уж проводить, то было примерно так Один , Ordu (ok), 23:27 , 06-Янв-20, (262) +2 //

Как же тогда футболисты играют на снегу в футбол в бутсах, а не в валенках Бутс, Аноним (341), 13:58 , 07-Янв-20, (341) –1 //

Ты уж определись, они играют в футбол на траве Или в футбол на снегу , Ordu (ok), 15:19 , 07-Янв-20, (344)

Это ты начал про снег А в футбол и на траве и на снегу бутсы то что доктор проп, Аноним (367), 00:29 , 08-Янв-20, (366)

Да, ты верно подметил По обоим пунктам Теперь тебе осталось подметить, что дов, Ordu (ok), 01:52 , 08-Янв-20, (369)

Единственная этом случае правильная аналогия это что в бутсах неудобно разгружат, Аноним (383), 16:03 , 08-Янв-20, (383) +1

Один человека говорит, что запускать компьютерные игры - это основная обязанност, антонимус (?), 23:53 , 06-Янв-20, (275) +1 //

Я и сам раньше так думал , Аноним (341), 12:56 , 07-Янв-20, (331) +1

Линус подтвердил что линукс - серверная ОС, которая не подходит для десктопа Та, Аноним (263), 23:20 , 06-Янв-20, (258) +5 //

Ты повторяешь мифы 20 летней давности, уже лет 15 как это всё не актуально , Аноним (158), 23:25 , 06-Янв-20, (261) –2 //

Да я это у себя всё наблюдаю Начиная со жрущей CPU как не в себя графики, криво, Аноним (263), 23:34 , 06-Янв-20, (266) //

а я такого у себя не наблюдаюпопробуйте докер и кубернетис с виртуалками удалит, Аноним (11), 23:39 , 06-Янв-20, (267) +1
хз ютуб работает ок и не лагает - комп ноут 10 летней давности, не жужжит , Аноним (11), 23:42 , 06-Янв-20, (268) +2
Это проблемы кривых браузеров, не хотят их разработчики они линукс за платформу , Аноним (158), 23:44 , 06-Янв-20, (269)

Пользователю как-то всё равно с чьей стороны проблема Если браузер хреново рабо, Аноним (263), 00:07 , 07-Янв-20, (282) –1

А, то есть сейчас даже старый добрый сисрку комбинация не спасает Только кнопко, Аноним (327), 11:57 , 07-Янв-20, (327)

Ваше мнение чрезвычайно важно участникам форума Продолжайте наблюдение , антонимус (?), 23:58 , 06-Янв-20, (278)

Вот человек наблюдает, делится информацией, другие читают об этом, узнают, что н, Аноним (317), 09:33 , 07-Янв-20, (320)

Если что-то плохо работает, об этом надо багрепорты писать Но, конечно, если ни , Аноним (93), 15:06 , 09-Янв-20, (400)

Зачем вы пишите очевидные вещи Это и так понятно Спасибо, насмешили , Аноним (410), 17:57 , 09-Янв-20, (410)

Винда 10 грузится минут 10 и тормозитНа линуксе загрузка меньше минутыПользовате, Аноним (254), 23:30 , 06-Янв-20, (264) //

Можно попробовать отключить гибридную гибернацию или как её там у десяточки, так, Аноним (158), 23:50 , 06-Янв-20, (274)
что за комп в десятке надо сразу обязательно выключать защитник и не ставить д, unnamed11111 (?), 00:05 , 07-Янв-20, (281) //

какойто 6 ядерный amd купленый лет 10 или больше назад 8gb памяти hdd дискзащитн, Аноним (11), 13:19 , 07-Янв-20, (336)

какойто 6 ядерный amd купленый лет 10 или больше назад 8gb памяти hdd диск от, unnamed11111 (?), 21:21 , 07-Янв-20, (360)

Вообще одна из больших проблем винды - она не настроена изнанчально и настраивае, unnamed11111 (?), 21:25 , 07-Янв-20, (362)

Ставь 1909 со всеми обновлениями Всё что позже 15хх мсовцы разломали и только н, Аноним (249), 03:00 , 07-Янв-20, (297) //

я редко загружаю windows 10но когда это делаю - система всегда любезно предлагае, Аноним (11), 13:22 , 07-Янв-20, (338)

Линус подтвердил только то, что если хочешь написать правильный софт, учи докуме, антонимус (?), 23:55 , 06-Янв-20, (277)

На самом деле Линус не объективен по этому вопросу и пытается давить авторитетом, Аноним (263), 23:47 , 06-Янв-20, (272) –1 //

чтоже мешает такой корпорации как google c немерянными бюджетами сделать все пра, Аноним (11), 23:54 , 06-Янв-20, (276) //

гуглу мешает авторитет Торвальдса, не иначе , антонимус (?), 00:00 , 07-Янв-20, (279)
Да ничего не мешает Так же как они допатчили линукс до нужного им Android а, та, Аноним (263), 00:09 , 07-Янв-20, (283) //

что же они этого еще не сделали сервис уже запустили вроде но вместо того чтобы, Аноним (11), 13:14 , 07-Янв-20, (334)

На самом деле чувак перед тестами даже man не прочитал где всё это описано прямы, Аноним (306), 06:20 , 07-Янв-20, (311) +4
А кто объективен Анон с пoпeннета , Аноним (-), 13:23 , 07-Янв-20, (339)

Гуглстадия там же и гуглгласс и еще миллион проектов от гугла, Аноним (313), 08:31 , 07-Янв-20, (313) //

Линус определенно приложил к этому руку То нвидии палец покажет, то гуглу вот т, Аноним (341), 13:04 , 07-Янв-20, (332)
Гуглстадия через год закроется, как 90 их проектов , Аноним (-), 13:21 , 07-Янв-20, (337) +1 //

Как 146 скорее просто переименуют А стриминг есть не только от гугла , Аноним (341), 14:01 , 07-Янв-20, (342) //

Нет Закроют Т к стримминговый сервис нужен, как корове пятое седло Вот когда , Аноним (371), 06:38 , 08-Янв-20, (372)

Нет, Аноним (383), 15:58 , 08-Янв-20, (382)

пф, почему бы не распилить планировщик на два других даже такое хомоюзер, как я,, darkshvein (ok), 13:51 , 07-Янв-20, (340) +1 //

1 Монолит2 Нафига , Аноним (371), 06:39 , 08-Янв-20, (373) –1

Что ж, Линус пошёл в отрицание, закономерная реакция Отзывчивость Линукса на де, Аноним (346), 15:43 , 07-Янв-20, (346) –4 //

Страдает, только проблема там совсем другая , Аноним (231), 02:21 , 09-Янв-20, (390)

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

42. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (42), 06-Янв-20, 12:04

https://www.techpowerup.com/review/1usmus-custom-power-plan-.../
Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it.
В линуксе вот этот момент гораздо правильней реализован

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

61. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +4 +/–

Сообщение от Аноним (26), 06-Янв-20, 13:10

Угу. Процитирую эту статью:
> Windows considers a core as "busy" even if there is only a single thread using it and moves that same thread to an idle core if one is available!
Ну, во первых, термина "busy" в планировщике Windows вообще нет (есть только его противоположность, idle). Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит. Советую почитать Windows Internals, например 7-ое издание. Там и терминология соответствующая, и материал соответствующий Windows 10 района 2016 года (например, там всё ещё Stride, а не StrideMask в KPRCB, т.е. нововведения для поддержки новых Ryzen там не покрыты).
> Furthermore, the Windows process scheduler makes no distinction whatsoever between physical and virtual cores, nor between CCXes with their separate caches.
Как минимум Windows 8 и выше прекрасно в курсе HT/SMT и в самом планировщике. Даже Windows 7 старалась сдвигать работу на физические ядра. Про детали CCX ничего не знаю, поэтому утверждать не буду.
> Just to clarify: the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware.
Это неверно как следствие первых двух ошибок.
В этой же статье далее рассказывается про их power plan, который делает "всё правильно". Но ничего не упоминается даже про то, что Microsoft дропает поддержку кастомных планов, и что на достаточно современных планшетах и ноутбуках всего один, новый, динамический план питания. Что весьма странно и, в совокупности с фактическими ошибками, не вызывает доверия к их экспертному мнению.
Возможно (даже вероятно) планировщик в Linux сложнее, способен обрабатывать даже очень невероятные ситуации. Я лишь утверждаю, что планировщик в Windows тоже неплох, да ещё и развивается.

Ответить | Правка | Наверх | Cообщить модератору

69. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +1 +/–

Сообщение от Аноним (6), 06-Янв-20, 13:40

> Угу. Процитирую эту статью:
>> Windows considers a core as "busy" even if there is only a single thread using it and moves that same thread to an idle core if one is available!
> Ну, во первых, термина "busy" в планировщике Windows вообще нет (есть только
> его противоположность, idle).
Ну как бы ядро (т.е. исполнитель) и тред (контекст исполнения, в т.ч. адрес исполняемого кода) и есть "противоположности".
; set context swap busy for the idle thread and acquire the PRCB Lock.
;
        mov     rdi, PbIdleThread[rbx]  ; get idle thread address
ifndef NT_UP
        mov     byte ptr ThSwapBusy[rdi], 1 ; set context swap busy

https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/amd64/...
> Во вторых, смена процессора выполнения потока "просто потому
> что появилось idle ядро" никогда не происходит.

; The new thread is the Idle thread (same as old thread).  This can happen
; rarely when a thread scheduled for this processor is made unable to run
; on this processor. As this processor has again been marked idle, other
; processors may unconditionally assign new threads to this processor.

https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/amd64/...
Интересно было бы поискать это "unconditionally" условие, но я не делал утверждения "никогда не происходит".)

Ответить | Правка | Наверх | Cообщить модератору

103. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +1 +/–

Сообщение от Аноним (26), 06-Янв-20, 14:49

Люблю когда по делу переписка.
По первому куску кода WRK:
Не знаю, зачем сюда уже подмешивать механизм context swap, который чаще всего выполняется в конце работы планировщика.
По второму куску кода WRK:
К чему он вообще? Он отвечает за завершение итерации idle loop, когда новый поток выполнения не найден, или найден, но на него переключиться нельзя (по разным причинам, например изменение affinity после перехода в standby режим потока).
Unconditionally - это скорее подчёркивает, что поскольку этот поток ничего полезного не делает (только спиннит ядро в ожидании работы), то никаких дополнительных условий при выборе ядра для нового потока в очереди выполнения проверять не надо.
> Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит.
Я пишу про то, что поток, выполнявшийся на одном ядре, без очень весомой причины (до сборки 19536, в ней это стало происходить чаще благодаря новому Cache Aware Scheduling) не станет выполняться на другом ядре, т.к. Ideal processor чаще всего остаётся неизменным в thread lifecycle.
Ну и в целом, приводить в пример урезанное ядро Windows XP - скучно. Реверс Windows 10 - совсем иные ощущения.
Зато я нашёл ошибку в своём начальном посте: Stride - свойство KNODE конечно, а не KPRCB (ноды, а не конкретного ядра).

Ответить | Правка | Наверх | Cообщить модератору

136. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (6), 06-Янв-20, 16:06

> Люблю когда по делу переписка.
Э, нет, дружище, я тут не весть какой помощник. Мне это было интересно, когда сорцы WRK доступны не были.
> По первому куску кода WRK:
> Не знаю, зачем сюда уже подмешивать механизм context swap, который чаще всего
> выполняется в конце работы планировщика.
Не читал первую ссылку, но исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил. Из вышеприведённого или подобного куска. Ссылка на KiIdleLoop - намёк на казалось бы просто вопрос "на каком IRQL выполняется спящий поток?", которым можно много кого завалить.
> По второму куску кода WRK:
> К чему он вообще? Он отвечает за завершение итерации idle loop, когда
> новый поток выполнения не найден, или найден, но на него переключиться
> нельзя (по разным причинам, например изменение affinity после перехода в standby
> режим потока).
> Unconditionally - это скорее подчёркивает, что поскольку этот поток ничего полезного не
> делает (только спиннит ядро в ожидании работы), то никаких дополнительных условий
> при выборе ядра для нового потока в очереди выполнения проверять не
> надо.
К "просто потому что появилось idle ядро", которую каждый понял по-своему. Тут как раз "swap from idle to idle".
>> Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит.
> Я пишу про то, что поток, выполнявшийся на одном ядре, без очень
> весомой причины (до сборки 19536, в ней это стало происходить чаще
> благодаря новому Cache Aware Scheduling) не станет выполняться на другом ядре,
> т.к. Ideal processor чаще всего остаётся неизменным в thread lifecycle.
К примеру, у нас 2 ядра и 4 потока. 2 выполняются на одном ядре, 2 на другом. Первые 2 завершились. Это весомая причина? Понятно, что должно быть перераспределение.
> Ну и в целом, приводить в пример урезанное ядро Windows XP -
> скучно. Реверс Windows 10 - совсем иные ощущения.
Представляю, какие были ощущения у online-solutions.ru
когда MS выкатило очередной подарок. :)
> Зато я нашёл ошибку в своём начальном посте: Stride - свойство KNODE
> конечно, а не KPRCB (ноды, а не конкретного ядра).
А что, сейчас такие вещи нигде толком не обсуждаются?

Ответить | Правка | Наверх | Cообщить модератору

170. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 06-Янв-20, 17:39

> исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил.
Вероятнее всего. Вопрос - понимает ли автор, что стоит за этим словом?
> на каком IRQL выполняется спящий поток?
Да, занятный, но я бы на него ответил контрвопросом "в какой-то конкретный момент или в целом?". Но вообще это наверное для проверки на вшивость разработчика драйверов, нежели ради реальных знаний.
> Понятно, что должно быть перераспределение.
Да, но оно не* результат перераспределения как такового, а, например, результат поиска работы того же idle thread. Но Ideal процессор то не менялся.
> Представляю, какие были ощущения у online-solutions.ru
> когда MS выкатило очередной подарок.
Кто это? Никогда о них не слышал. Вот у настоящих производителей антивирусных пакетов я думаю неплохо так горит от каждого обновления Windows, ибо их любимый хардкод и хаки начинают рассыпаться (и вводить в BSoD/GSoD или приводить к ошибке обновления до новой версии).
> А что, сейчас такие вещи нигде толком не обсуждаются?
Есть любители поковырять ядро, но обычно знания остаются у расковырявшего. Увы.

Ответить | Правка | Наверх | Cообщить модератору

202. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (6), 06-Янв-20, 19:19

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

Ответить | Правка | Наверх | Cообщить модератору

173. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Anonymoustus (ok), 06-Янв-20, 17:46

> Реверс Windows 10 - совсем иные ощущения.
Ну и что там внутри, мой анонимный брат?

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

176. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 06-Янв-20, 17:54

Гора неочевидного кода, твой анонимный брат. Неочевидного - потому что ты не знаешь настоящей причины, зачем он там. А ведь он нужен.
Ах да, это же прямо как исходники Linux, с патчсетами от крупных компаний-производителей процессоров, спеки то всё равно только они имеют. Конец минутки неудачной иронии.

Ответить | Правка | Наверх | Cообщить модератору

212. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Anonymoustus (ok), 06-Янв-20, 19:54

> Гора неочевидного кода, твой анонимный брат. Неочевидного - потому что ты не
> знаешь настоящей причины, зачем он там. А ведь он нужен.
Ох уж эти индусы…

> Ах да, это же прямо как исходники Linux, с патчсетами от крупных
> компаний-производителей процессоров, спеки то всё равно только они имеют. Конец минутки
> неудачной иронии.
«Это свобода!» — говорили они нам лет около двадцати назад.

Ответить | Правка | Наверх | Cообщить модератору

81. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Ordu (ok), 06-Янв-20, 14:00

Хочу уточнить: твои придирки, как я понял, относятся не к фактической части, а к теоретической? То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро, тебя не устраивает то, как эти перекидывания объясняются, так?

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

129. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 06-Янв-20, 15:28

> То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро,
Я утверждаю, что их нет (до введения Cache Aware Scheduling пару недель назад).
> тебя не устраивает то, как эти перекидывания объясняются, так?
Меня не устраивают неверные утверждения про то что современный планировщик Windows не в курсе про SMT/HT/NUMA/архитектуру Ryzen, или что он имеет всего одну глобальную очередь потоков на выполнение  (или даже что он имеет одну локальную для ядра очередь потоков). А следовательно - про его простоту.

Ответить | Правка | Наверх | Cообщить модератору

149. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Ordu (ok), 06-Янв-20, 17:03

>> То есть ты не споришь с тем, что венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро,
> Я утверждаю, что их нет (до введения Cache Aware Scheduling пару недель
> назад).
В смысле, они были до введения Cache Aware Scheduling пару недель назад, я правильно понял? Статья от ноября 2019 года. То есть она всё говорит правильно.

Ответить | Правка | Наверх | Cообщить модератору

178. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 06-Янв-20, 17:59

Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений, вывести противоположное утверждение? НЕ было. Так ясно?
В статье лажа не по этой причине, а из-за следующих двух параграфов с голословными заявлениями (и противоречащим реалиям, если посмотреть код или почитать авторитетные источники вроде Windows Internals), ставящих под сомнение всё их экспертное мнение.

Ответить | Правка | Наверх | Cообщить модератору

194. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (156), 06-Янв-20, 18:55

Где это такое видано чтобы оба сабжевых оратора были не правы? Либо черное либо белое. Либо один прав, либо другой, третьего не дано. Таков путь.

Ответить | Правка | Наверх | Cообщить модератору

204. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Ordu (ok), 06-Янв-20, 19:23

> Как так можно читать, чтобы из двух, вроде бы чётко написанных сообщений,
> вывести противоположное утверждение?
Как можно писать, что я читаю одно твоё сообщение за другим, и до сих пор продолжаю уточнять, что именно ты имеешь в виду?
> НЕ было. Так ясно?
Нет, не ясно. Чего именно не было? Те графики в статье показывающие как поток выполенения перепрыгивает с ядра на ядро -- туфта нарисованная в фотошопе?
> В статье лажа не по этой причине,
"Не по этой" -- это не по какой? Я простите не телепат, чтобы угадывать, на что именно ты ссылаешься всеми этими своими местоимениями.

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

214. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 06-Янв-20, 19:56

> они были до введения Cache Aware Scheduling пару недель назад
> НЕ было. Так ясно?
> Нет, не ясно. Чего именно не было?
:/ Поток перепрыгивает с ядра на ядро не по причине "планировщик неоправданно переключить ядро", как в начальном вопросе:
> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
А по причине того, что ядро освобождается, и ищет работу. Оно находит работу в очереди у другого ядра (если повезёт - в той же ноде или ноде с теми же характеристиками). Оно обрабатывает её, вместо простоя. Где ненужность?
> "Не по этой" -- это не по какой?
Не по тобою же обозначенной в первом же твоём сообщении (и статье).
> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
> Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it.
А реальная лажа в статье в утверждениях:
> Furthermore, the Windows process scheduler makes no distinction whatsoever between physical and virtual cores, nor between CCXes with their separate caches.
Планировщик Windows знает про HT. Про CCX я не знаю, ничего утверждать не буду.
> the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware.
Планировщик Windows тоже знает про SMT.
> Linux handles this rather better: it actively prefers to keep threads on the same core for as long as there are no scheduling conflicts on that core.
Планировщик Windows тоже предпочитает оставлять потоки на последнем ядре выполнения. Но может и сменить.

Ответить | Правка | Наверх | Cообщить модератору

234. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." –1 +/–

Сообщение от Ordu (ok), 06-Янв-20, 21:12

>> они были до введения Cache Aware Scheduling пару недель назад
>> НЕ было. Так ясно?
>> Нет, не ясно. Чего именно не было?
> :/ Поток перепрыгивает с ядра на ядро не по причине "планировщик неоправданно
> переключить ядро", как в начальном вопросе:
>> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
> А по причине того, что ядро освобождается, и ищет работу. Оно находит
> работу в очереди у другого ядра (если повезёт - в той
> же ноде или ноде с теми же характеристиками). Оно обрабатывает её,
> вместо простоя. Где ненужность?
В перекидывании потока: за ним ведь приходится тянуть все кеши. Какая разница планировщику какие ядра будут простаивать без работы? Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное? Что от этого изменится в лучшую сторону?
Ничего в лучшую сторону не изменится, а вот накладные расходы будут. Значит перекидывания ненужные.
>> "Не по этой" -- это не по какой?
> Не по тобою же обозначенной в первом же твоём сообщении (и статье).
>> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро
>> Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it.
Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе? На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
Если графики не были нарисованы в фотошопе, то вот тогда у меня появится следующий вопрос: как эти графики можно объяснить, не прибегая к словам "ненужные перекидывания потоков", "dumb Windows scheduler" и тому подобных?
> А реальная лажа в статье в утверждениях:
Я отмечу, что ты не предлагаешь никакой альтернативы им. Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.

Ответить | Правка | Наверх | Cообщить модератору

318. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +1 +/–

Сообщение от Аноним (26), 07-Янв-20, 09:18

> В перекидывании потока: за ним ведь приходится тянуть все кеши.
Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его квант истёк, его вытеснил поток B. Вдруг ядро 2 начало простаивать, а A стоит в очереди на ядро 0, которое находится в той же ноде, что и ядро 2. Ядро 2 должно простаивать? Или может всё таки лучше забрать поток A себе? Планировщик скорее всего сделает последнее (за вычетом ограничений affinity и подобного). Кэши просто так никто перетягивать не будет. Поток B вероятнее всего уже весь кэш L1 заполнил своими данными. А L2 может вообще быть общим для ядер 0 и 2. Что перетягивать? Как перетягивать? Да, будут cache miss'ы. Но это лишь замедление работы, а не полное простаивание ядра (пока есть работа в очереди).
> Какая разница планировщику какие ядра будут простаивать без работы?
Они не будут (простаивать без работы). См. выше.
> Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное?
Не зачем. Но поток не может вечно крутится на ядре. Он может крутится лишь определённый кусок времени (квант), затем он должен уступить другим потокам. В этот момент и может произойти ситуация, описанная выше, где поток A - это как раз "поток кушающий 100% времени процессорного ядра".
> Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе?
Нет, конечно. Потоки могут выполняться не только на последнем использованном для выполнения ядре, они действительно могут "перекидываться". См. пример выше.
> На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на твоё первое сообщение 4.81.
> Я отмечу, что ты не предлагаешь никакой альтернативы им.
В моём же сообщении 3.61 я сразу написал:
> Советую почитать Windows Internals, например 7-ое издание.
Ибо там, даже если очень лень вникать, просто из содержания можно извлечь ложность утверждений из статьи.
> Thread selection on multiprocessor systems
> Heterogeneous scheduling (big.LITTLE)
Про то, что планировщик Windows знает, про разницу между физическими и логическими ядрами, рассказывает раздел "Package sets and SMT sets", но увы, тут уже придётся вчитаться хотя бы в первый его параграф.
> Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
Я не знаток конечно, я лишь консультирую по NT Internals. Зачем я должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? Смысл пересказывать содержимое книги?

Ответить | Правка | Наверх | Cообщить модератору

328. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +1 +/–

Сообщение от Ordu (ok), 07-Янв-20, 12:09

>> В перекидывании потока: за ним ведь приходится тянуть все кеши.
> Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его
> квант истёк, его вытеснил поток B.
С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают?
>> Какая разница планировщику какие ядра будут простаивать без работы?
> Они не будут (простаивать без работы). См. выше.
Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем? Там в любой момент времени, потребляется 100-101% времени одного ядра, потому что есть один поток жрущий 100% одного ядра, и фоновые процессы, которые практически всё время спят.
>> На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил.
> Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на
> твоё первое сообщение 4.81.
В моём первом сообщении был вопрос: "твои придирки, как я понял, относятся не к фактической части, а к теоретической?". Фактическая часть -- это как раз те самые графики, которые демонстрируют как имея несколько свободных ядер, венда перекидывает поток жрущий 100% времени одного ядра между ядрами. Теоретическая часть -- это объяснение происходящего с отсылками к устройству планировщика задач венды.
>> Я отмечу, что ты не предлагаешь никакой альтернативы им.
> В моём же сообщении 3.61 я сразу написал:
>> Советую почитать Windows Internals, например 7-ое издание.
Иди ты с этой альтернативой знаешь куда? Мне венда не въелась совершенно, из любопытства я могу почитать обсуждаемую статью, чтобы узнать немного о том, как она работает. Но всякие вендовс интерналс я прекратил читать лет двадцать назад, когда заглянул в linux и увидел, что здесь можно читать не дурацкую писанину технических писателей, а непосредственно исходный код.
>> Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
> Я не знаток конечно, я лишь консультирую по NT Internals.
Лол. Мне нравятся твои консультации: "идите и почитайте windows internals". Тебе за такие советы реально кто-то платит денег? Вообще, насколько я понимаю задачу консультирования, в ней очень важно иметь навык понимания собеседника, потому как ежели консультант не в состоянии понять того, кого он консультирует, то он действительно никогда не сможет дать совета лучше, чем "RTFM". Второй важный навык -- это умение объяснять и отвечать на вопросы. Ты здесь и сейчас продемонстрировал, что ни один из этих навыков тебе недоступен. Я чёрть-его-знает-сколько времени выуживал из тебя ответы на простые вопросы, получая ненужные мне ответы на вопросы, которых я не задавал. Как ты вообще работаешь консультантом при этом?
В качество профориентационного совета: тебе лучше податься в маркетинг или в политику -- там как раз очень полезно умение уходить от прямых вопросов, создавая при этом впечатление открытости и готовности развёрнуто отвечать на любые вопросы.
> Зачем я
> должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек,
> если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков?
> Смысл пересказывать содержимое книги?
Мне не нужно содержимое книги, мне хочется знать короткое объяснение простому феномену: почему венда жонглирует потоком между свободными ядрами, хотя оно могло бы оставить его крутится на одном ядре.

Ответить | Правка | Наверх | Cообщить модератору

330. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 07-Янв-20, 12:55

> С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают?
"С какого полового члена" взято что они простаивают? Из сценария из статьи, точнее из графика из неё, из которого не понятно даже это нагрузка от одного процесса или от всей системы? Я про свой сценарий, который может совпадать со сценарием из статьи, когда помимо одного однопоточного приложения есть неравномерная нагрузка и на остальные ядра (от других процессов), но не 100%.
> Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем?
Конечно читал, ибо реагирую.
> В моём первом сообщении был вопрос: "твои придирки, как я понял, относятся не к фактической части, а к теоретической?". Фактическая часть -- это как раз те самые графики, которые демонстрируют как имея несколько свободных ядер, венда перекидывает поток жрущий 100% времени одного ядра между ядрами. Теоретическая часть -- это объяснение происходящего с отсылками к устройству планировщика задач венды.
Если так поставить, да. Мои "придирки", "относятся не к фактической части, а к теоретической".
Ну и спасибо за полезные советы, я ими непременно воспользуюсь по назначению.

Ответить | Правка | Наверх | Cообщить модератору

335. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." –1 +/–

Сообщение от Ordu (ok), 07-Янв-20, 13:18

>> С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают?
> "С какого полового члена" взято что они простаивают? Из сценария из статьи,
> точнее из графика из неё, из которого не понятно даже это
> нагрузка от одного процесса или от всей системы?
Посмотри внимательно на график. Там две кривые прыгают вверх-вниз -- это два ядра, между которыми прыгает поток. А внизу, около нуля, ещё несколько кривых -- это все остальные ядра.
> Я про свой
> сценарий, который может совпадать со сценарием из статьи,
Да кому он нужен твой сценарий, если в статье идёт обсуждение вполне конкретного сценария? И вообще, если ты меняешь сценарий, ты хоть предупреждай собеседников. Я бы даже не парился общаться с тобой, если бы с самого начала знал, что ты на своей волне сам с собой разговариваешь.
>> Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем?
> Конечно читал, ибо реагирую.
https://www.physics-astronomy.org/2019/04/marijuana-contains...

Ответить | Правка | К родителю #330 | Наверх | Cообщить модератору

345. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +1 +/–

Сообщение от Аноним (26), 07-Янв-20, 15:26

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

Ответить | Правка | К родителю #335 | Наверх | Cообщить модератору

354. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Ordu (ok), 07-Янв-20, 20:04

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

Ответить | Правка | К родителю #345 | Наверх | Cообщить модератору

358. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 07-Янв-20, 21:09

Я уже начинаю уставать от этого диалога, если честно.
Я не говорю, что автор графика накосячил (вероятнее всего ошибок в графике нет, хотя к нему не хватает комментариев). Я утверждаю, что подобное поведение (перескакивание потока с ядра на ядро) легко объясняется без пинков в сторону "примитивности" планировщика. Я предоставляю очень вероятный сценарий (в сообщении 11.318), в котором график абсолютно корректен.
Дополню сценарий дополнительными комментариями:
Планировщик, запускаемый на только что освободившемся ядре 2 (которое могло выполнять очень лёгкую работу, и/или в конце добровольно отдавать управление, поэтому на графике, даже если это график полной нагрузки каждого ядра, оно могло быть любым кол-вом процентов), решает забрать нашу сложную ("single-threaded workload", поток A из 11.318) работу у ядра 0, которая недавно была вытеснена другим потоком по причине истечения кванта времени (SMT, preemptive scheduling). Это позволяет избежать простаивания на любом ядре в любой момент времени (что, конечно, хорошо), но да, это действительно перекидывание потока с ядра на ядро. Да, оно ведёт к L1 cache miss, но есть хороший шанс (обеспеченный алгоритмически, ибо планировщик Windows знает про сеты процессоров и NUMA ноды), что L2 или L3 всё ещё содержат нужные данные.
Подчеркну, что ядро 0, отдав наш поток A, могло начать заниматься чем угодно (любая ненулевая нагрузка любой сложности), но это должно было бы произойти (если есть хотя бы один ещё поток в очереди), ядро должно хотя бы иногда переключать контекст (опять, кванты времени). А ядро 2 могло в любой момент (разумеется, после того, как ядро 0 переключилась с потока А) украсть поток A, чтобы не простаивать. Объективно, это позволяет эффективнее использовать все ядра.
В статье же, по незнанию автора (статьи, ибо автор статьи и графика может не совпадать) этот эффект истолковывается иначе (и делаются неверные выводы), якобы ядро 2 крадёт поток A у ядра 0 только потому, что оно освободилось (в реальности ядро 0 просто отключилось от потока A по расписанию, и начало другую работу; если другой работы бы не было, планировщик продлил бы т.н. Quantum Target и вернул управление потоку A). Утверждая про некорректное истолкование, я напрямую опираюсь на чётко описанный материал в самой авторитетной технической книге по внутренностям Windows.

Ответить | Правка | К родителю #354 | Наверх | Cообщить модератору

370. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Ordu (ok), 08-Янв-20, 02:06

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

Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

374. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..." +/–

Сообщение от Аноним (26), 08-Янв-20, 10:55

> Да, тогда когда занятых работой потоков больше чем ядер.
Это практически всегда так. На моём домашнем десктопе с 6 логическими ядрами, даже с незапущенным IIS и SQL Server, порядка 240 процессов и 4300 потоков. 0% ни на одно ядро я никогда не наблюдаю.
> Ему бы следовало мониторить активность задач, и заметить, что одна задача серьёзно занята чем-то и хочет сожрать столько процессорных квантов, сколько возможно,
Угу, он это и делает.
В Windows Server базовый квант времени (Quantum Reset) в 4 раза дольше, чем в Windows, специально чтобы снизить количество переключений контекста, но и в клиентских редакциях можно включить такой квант. В клиентских редакциях настоящий квант времени зависит от типа процесса: foreground/background, что тоже может продлевать квант времени. Также есть механизм Priority Boost, но он зависит от конкретной "single-threaded workload".
Когда заканчивается квант времени, почти всегда будет использован механизм, который позволяет просто продлить квант времени. Можно повысить приоритет (понизить niceness в Linux), тогда переключение потока на ядре будет ещё реже.
> суммарная производительность остальных ядер более чем в 100 раз больше, чем требуется остальным задачам
Очень опасное наблюдение, которое целиком опирается на неизменность нагрузки потоков (что, вообще говоря, очень большая редкость). Планировщик Windows записывает историю нагрузки, и использует её, но не на горячем пути планировщика, а в более редких/сложных ситуациях (см. далее).
> шедулить остальные задачи по свободным ядрам
Так и происходит, это свободные ядра сами делают (планировщик, запускаемый в их контексте).
Перекидывание может произойти в редком случае: все остальные потоки приоритета потока A и выше не готовы к выполнению. Чем "дальше" два ядра, тем меньше вероятность перекидывания (т.к. планировщик знает про конфигурацию ядер и итеративно расширяет поиск готовых к исполнению потоков, но до определённого порога, обычно границей является NUMA нода). Как видно из того же графика (опять, на нём нет даже масштаба времени), перекидывание практически всегда происходит между двумя (редко - тремя) ядрами (а в Zen 2 каждый CCX содержит 4 ядра!).
---
Почитал я про стандартный CFS (опирался на Wikipedia, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-de.../ и на https://opensource.com/article/19/2/fair-scheduling-linux). Ни в коей мере не утверждаю правильность понимания, но следующий набор замечаний.
> The CFS scheduler has a target latency, which is the minimum amount of time—idealized to an infinitely small duration—required for every runnable task to get at least one turn on the processor.
> Of course, an idealized infinitely small duration must be approximated in the real world, and the default approximation is 20ms. Each runnable task then gets a 1/N slice of the target latency, where N is the number of tasks.
Немного (сильно) противоречит утверждению:
> сильно занятая задача будет "захватывать" ядро на несколько секунд за раз, а не на 40 миллисекунд в среднем.
Или это про то, что CFS будет всегда возвращать управление "сильно занятой задаче"? Но всё равно, что с остальными потоками в очереди? Никогда не получат ядро?
Далее вводится очень разумный концепт minimum granularity, затем знакомый термин virtual runtime (vruntime) (в Windows эта метрика более чёткая, в плане, на пару счётчиков больше).
> Suppose task T1 has run for its weighted 1/N slice, and runnable task T2 currently has the lowest virtual runtime (vruntime) among the tasks contending for the processor. The vruntime records, in nanoseconds, how long a task has run on the processor. In this case, T1 would be preempted in favor of T2.
> The scheduler tracks the vruntime for all tasks, runnable and blocked. The lower a task's vruntime, the more deserving the task is for time on the processor. CFS accordingly moves low-vruntime tasks towards the front of the scheduling line. Details are forthcoming because the line is implemented as a tree, not a list.
Но ведь это означает, что та самая "single-threaded workload" будет иметь очень большой vruntime и всегда оказываться далеко в "очереди" (которая на самом деле дерево) на исполнение, т.е. она всегда будет уступать более лёгким/быстрым (термин мой) потокам. Не проблема, но интересное замечание.
> Yet configurable scheduling domains can be used to group processors for load balancing or even segregation. If several processors share the same scheduling policy, then load balancing among them is an option; if a particular processor has a scheduling policy different from the others, then this processor would be segregated from the others with respect to scheduling.
В планировщике Windows это называется processor package, так что это знакомо.
Затем я открываю статью "The Linux Scheduler: a Decade of Wasted Cores", патчи из которой, как я слышал, были приняты в планировщик несколько лет назад. Интересный материал, затем я дохожу до этого момента:
> Now we have a new problem of balancing work across multiple runqueues.
> Suppose that one queue has one low-priority thread and another has ten high-priority threads.
> We could have each core check not only its runqueue but also the queues of other cores, but this would defeat the purpose of per-core runqueues.
Вот, серьёзное алгоритмическое отличие от планировщика Windows. Планировщик Windows полезет в очереди других ядер в порядке удалённости от текущего. В то время как CFS:
> Therefore, what Linux and most other schedulers do is periodically run a load-balancing algorithm that will keep the queues roughly balanced.
> Since load balancing is expensive the scheduler tries not to do it more often than is absolutely necessary. In addition to periodic load-balancing therefore, the scheduler can also trigger emergency load balancing when a core becomes idle.
Как я понимаю, Windows предпочитает балансировать нагрузку "здесь и сейчас", когда ядро готово войти в состояние простоя, а CFS выделяет это в отдельную регулярно запускающуюся рутину (с возможностью экстренного запуска как в Windows). Сравнивать лучше/хуже не буду, но отмечу, что подход CFS более предсказуем, в то время как планировщик Windows почти* всегда работает в контексте "надо прямо сейчас решить что дальше делать".
почти* - есть например отдельный алгоритм по борьбе с CPU Starvation и priority inversion, который работает вне контекста конкретного потока, но он асинхронный и работает как "консультант", рекомендуя правки к финальному решению планировщика Windows, опираясь на историю нагрузки каждого потока.
Сделаю вывод из прочитанного: Linux предпочитает простаивание ядер (если даже load balancing и перекинет все потоки кроме потока A на другие ядра), но удерживает (если load balancing так решит) потоки в пределах одной runqueue. Windows действует "жадно", решая, что лучше в каждый момент (но опираясь на историю в *некоторых* случаях), что может приводить к краже потоков, если эта кража дешёвая (внутри одного processor package, ибо более широкие поиски задействуются очень редко), а другой работы соответствующего приоритета нет. Это иногда случающееся перекидывание потоков имеет обоснование (снижение количества простаивающих ядер), но cache miss'ы могут случаться чаще (они весьма вероятны и на CFS, ибо если load balancing оставит хотя бы один другой поток на ядре, где выполняется поток A - точно так же будет борьба за L1 и L2 в течение каждого target granularity, а отношение ядер/потоков явно не в пользу ядер).

Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	42. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (42), 06-Янв-20, 12:04
	https://www.techpowerup.com/review/1usmus-custom-power-plan-.../ Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it. В линуксе вот этот момент гораздо правильней реализован
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	61. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+4 +/–
	Сообщение от Аноним (26), 06-Янв-20, 13:10
	Угу. Процитирую эту статью: > Windows considers a core as "busy" even if there is only a single thread using it and moves that same thread to an idle core if one is available! Ну, во первых, термина "busy" в планировщике Windows вообще нет (есть только его противоположность, idle). Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит. Советую почитать Windows Internals, например 7-ое издание. Там и терминология соответствующая, и материал соответствующий Windows 10 района 2016 года (например, там всё ещё Stride, а не StrideMask в KPRCB, т.е. нововведения для поддержки новых Ryzen там не покрыты). > Furthermore, the Windows process scheduler makes no distinction whatsoever between physical and virtual cores, nor between CCXes with their separate caches. Как минимум Windows 8 и выше прекрасно в курсе HT/SMT и в самом планировщике. Даже Windows 7 старалась сдвигать работу на физические ядра. Про детали CCX ничего не знаю, поэтому утверждать не буду. > Just to clarify: the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware. Это неверно как следствие первых двух ошибок. В этой же статье далее рассказывается про их power plan, который делает "всё правильно". Но ничего не упоминается даже про то, что Microsoft дропает поддержку кастомных планов, и что на достаточно современных планшетах и ноутбуках всего один, новый, динамический план питания. Что весьма странно и, в совокупности с фактическими ошибками, не вызывает доверия к их экспертному мнению. Возможно (даже вероятно) планировщик в Linux сложнее, способен обрабатывать даже очень невероятные ситуации. Я лишь утверждаю, что планировщик в Windows тоже неплох, да ещё и развивается.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (6), 06-Янв-20, 13:40
	> Угу. Процитирую эту статью: >> Windows considers a core as "busy" even if there is only a single thread using it and moves that same thread to an idle core if one is available! > Ну, во первых, термина "busy" в планировщике Windows вообще нет (есть только > его противоположность, idle). Ну как бы ядро (т.е. исполнитель) и тред (контекст исполнения, в т.ч. адрес исполняемого кода) и есть "противоположности". ; set context swap busy for the idle thread and acquire the PRCB Lock. ; mov rdi, PbIdleThread[rbx] ; get idle thread address ifndef NT_UP mov byte ptr ThSwapBusy[rdi], 1 ; set context swap busy https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/amd64/... > Во вторых, смена процессора выполнения потока "просто потому > что появилось idle ядро" никогда не происходит. ; The new thread is the Idle thread (same as old thread). This can happen ; rarely when a thread scheduled for this processor is made unable to run ; on this processor. As this processor has again been marked idle, other ; processors may unconditionally assign new threads to this processor. https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/amd64/... Интересно было бы поискать это "unconditionally" условие, но я не делал утверждения "никогда не происходит".)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 06-Янв-20, 14:49
	Люблю когда по делу переписка. По первому куску кода WRK: Не знаю, зачем сюда уже подмешивать механизм context swap, который чаще всего выполняется в конце работы планировщика. По второму куску кода WRK: К чему он вообще? Он отвечает за завершение итерации idle loop, когда новый поток выполнения не найден, или найден, но на него переключиться нельзя (по разным причинам, например изменение affinity после перехода в standby режим потока). Unconditionally - это скорее подчёркивает, что поскольку этот поток ничего полезного не делает (только спиннит ядро в ожидании работы), то никаких дополнительных условий при выборе ядра для нового потока в очереди выполнения проверять не надо. > Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит. Я пишу про то, что поток, выполнявшийся на одном ядре, без очень весомой причины (до сборки 19536, в ней это стало происходить чаще благодаря новому Cache Aware Scheduling) не станет выполняться на другом ядре, т.к. Ideal processor чаще всего остаётся неизменным в thread lifecycle. Ну и в целом, приводить в пример урезанное ядро Windows XP - скучно. Реверс Windows 10 - совсем иные ощущения. Зато я нашёл ошибку в своём начальном посте: Stride - свойство KNODE конечно, а не KPRCB (ноды, а не конкретного ядра).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	136. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (6), 06-Янв-20, 16:06
	> Люблю когда по делу переписка. Э, нет, дружище, я тут не весть какой помощник. Мне это было интересно, когда сорцы WRK доступны не были. > По первому куску кода WRK: > Не знаю, зачем сюда уже подмешивать механизм context swap, который чаще всего > выполняется в конце работы планировщика. Не читал первую ссылку, но исхожу из того, что её автор "busy" не сам придумал, а откуда-то выцепил. Из вышеприведённого или подобного куска. Ссылка на KiIdleLoop - намёк на казалось бы просто вопрос "на каком IRQL выполняется спящий поток?", которым можно много кого завалить. > По второму куску кода WRK: > К чему он вообще? Он отвечает за завершение итерации idle loop, когда > новый поток выполнения не найден, или найден, но на него переключиться > нельзя (по разным причинам, например изменение affinity после перехода в standby > режим потока). > Unconditionally - это скорее подчёркивает, что поскольку этот поток ничего полезного не > делает (только спиннит ядро в ожидании работы), то никаких дополнительных условий > при выборе ядра для нового потока в очереди выполнения проверять не > надо. К "просто потому что появилось idle ядро", которую каждый понял по-своему. Тут как раз "swap from idle to idle". >> Во вторых, смена процессора выполнения потока "просто потому что появилось idle ядро" никогда не происходит. > Я пишу про то, что поток, выполнявшийся на одном ядре, без очень > весомой причины (до сборки 19536, в ней это стало происходить чаще > благодаря новому Cache Aware Scheduling) не станет выполняться на другом ядре, > т.к. Ideal processor чаще всего остаётся неизменным в thread lifecycle. К примеру, у нас 2 ядра и 4 потока. 2 выполняются на одном ядре, 2 на другом. Первые 2 завершились. Это весомая причина? Понятно, что должно быть перераспределение. > Ну и в целом, приводить в пример урезанное ядро Windows XP - > скучно. Реверс Windows 10 - совсем иные ощущения. Представляю, какие были ощущения у online-solutions.ru когда MS выкатило очередной подарок. :) > Зато я нашёл ошибку в своём начальном посте: Stride - свойство KNODE > конечно, а не KPRCB (ноды, а не конкретного ядра). А что, сейчас такие вещи нигде толком не обсуждаются?
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


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


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


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


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


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


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


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


	214. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 06-Янв-20, 19:56
	> они были до введения Cache Aware Scheduling пару недель назад > НЕ было. Так ясно? > Нет, не ясно. Чего именно не было? :/ Поток перепрыгивает с ядра на ядро не по причине "планировщик неоправданно переключить ядро", как в начальном вопросе: > венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро А по причине того, что ядро освобождается, и ищет работу. Оно находит работу в очереди у другого ядра (если повезёт - в той же ноде или ноде с теми же характеристиками). Оно обрабатывает её, вместо простоя. Где ненужность? > "Не по этой" -- это не по какой? Не по тобою же обозначенной в первом же твоём сообщении (и статье). > венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро > Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it. А реальная лажа в статье в утверждениях: > Furthermore, the Windows process scheduler makes no distinction whatsoever between physical and virtual cores, nor between CCXes with their separate caches. Планировщик Windows знает про HT. Про CCX я не знаю, ничего утверждать не буду. > the Windows scheduler is not SMT aware—only the Windows core-parking algorithm is SMT aware. Планировщик Windows тоже знает про SMT. > Linux handles this rather better: it actively prefers to keep threads on the same core for as long as there are no scheduling conflicts on that core. Планировщик Windows тоже предпочитает оставлять потоки на последнем ядре выполнения. Но может и сменить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	234. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	–1 +/–
	Сообщение от Ordu (ok), 06-Янв-20, 21:12
	>> они были до введения Cache Aware Scheduling пару недель назад >> НЕ было. Так ясно? >> Нет, не ясно. Чего именно не было? > :/ Поток перепрыгивает с ядра на ядро не по причине "планировщик неоправданно > переключить ядро", как в начальном вопросе: >> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро > А по причине того, что ядро освобождается, и ищет работу. Оно находит > работу в очереди у другого ядра (если повезёт - в той > же ноде или ноде с теми же характеристиками). Оно обрабатывает её, > вместо простоя. Где ненужность? В перекидывании потока: за ним ведь приходится тянуть все кеши. Какая разница планировщику какие ядра будут простаивать без работы? Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное? Что от этого изменится в лучшую сторону? Ничего в лучшую сторону не изменится, а вот накладные расходы будут. Значит перекидывания ненужные. >> "Не по этой" -- это не по какой? > Не по тобою же обозначенной в первом же твоём сообщении (и статье). >> венда выполняет совершенно ненужные перекидывания потоков с ядра на ядро >> Windows loves to balance the CPU load across multiple CPU cores, moving threads from busy cores to idle ones. This is normal, expected behavior for a modern SMP-aware process scheduler, but Windows is actually pretty dumb about it. Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе? На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил. Если графики не были нарисованы в фотошопе, то вот тогда у меня появится следующий вопрос: как эти графики можно объяснить, не прибегая к словам "ненужные перекидывания потоков", "dumb Windows scheduler" и тому подобных? > А реальная лажа в статье в утверждениях: Я отмечу, что ты не предлагаешь никакой альтернативы им. Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	318. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Аноним (26), 07-Янв-20, 09:18
	> В перекидывании потока: за ним ведь приходится тянуть все кеши. Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его квант истёк, его вытеснил поток B. Вдруг ядро 2 начало простаивать, а A стоит в очереди на ядро 0, которое находится в той же ноде, что и ядро 2. Ядро 2 должно простаивать? Или может всё таки лучше забрать поток A себе? Планировщик скорее всего сделает последнее (за вычетом ограничений affinity и подобного). Кэши просто так никто перетягивать не будет. Поток B вероятнее всего уже весь кэш L1 заполнил своими данными. А L2 может вообще быть общим для ядер 0 и 2. Что перетягивать? Как перетягивать? Да, будут cache miss'ы. Но это лишь замедление работы, а не полное простаивание ядра (пока есть работа в очереди). > Какая разница планировщику какие ядра будут простаивать без работы? Они не будут (простаивать без работы). См. выше. > Без разницы, ну так и зачем двигать поток кушающий 100% времени процессорного ядра с занятого ядра на свободное? Не зачем. Но поток не может вечно крутится на ядре. Он может крутится лишь определённый кусок времени (квант), затем он должен уступить другим потокам. В этот момент и может произойти ситуация, описанная выше, где поток A - это как раз "поток кушающий 100% времени процессорного ядра". > Ты не ответил на вопрос: графики из статьи нарисованы в фотошопе? Нет, конечно. Потоки могут выполняться не только на последнем использованном для выполнения ядре, они действительно могут "перекидываться". См. пример выше. > На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил. Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на твоё первое сообщение 4.81. > Я отмечу, что ты не предлагаешь никакой альтернативы им. В моём же сообщении 3.61 я сразу написал: > Советую почитать Windows Internals, например 7-ое издание. Ибо там, даже если очень лень вникать, просто из содержания можно извлечь ложность утверждений из статьи. > Thread selection on multiprocessor systems > Heterogeneous scheduling (big.LITTLE) Про то, что планировщик Windows знает, про разницу между физическими и логическими ядрами, рассказывает раздел "Package sets and SMT sets", но увы, тут уже придётся вчитаться хотя бы в первый его параграф. > Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся. Я не знаток конечно, я лишь консультирую по NT Internals. Зачем я должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? Смысл пересказывать содержимое книги?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	328. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+1 +/–
	Сообщение от Ordu (ok), 07-Янв-20, 12:09
	>> В перекидывании потока: за ним ведь приходится тянуть все кеши. > Ну, нет. Представим ситуацию. Поток A всегда выполнялся на ядре 0. Его > квант истёк, его вытеснил поток B. С какого полового члена его вытеснил поток B если при этом ядра 1, 2, и 3 простаивают? >> Какая разница планировщику какие ядра будут простаивать без работы? > Они не будут (простаивать без работы). См. выше. Ты статью-то читал, на которую реагируешь? Графики смотрел, которые мы обсуждаем? Там в любой момент времени, потребляется 100-101% времени одного ядра, потому что есть один поток жрущий 100% одного ядра, и фоновые процессы, которые практически всё время спят. >> На самом деле, этот вопрос был задан в первом моём сообщении, я его повторял потом в разных вариациях, но ты так до сих пор на него и не ответил. > Про графики речь зашла лишь в твоём сообщении 8.204. Отвечал я на > твоё первое сообщение 4.81. В моём первом сообщении был вопрос: "твои придирки, как я понял, относятся не к фактической части, а к теоретической?". Фактическая часть -- это как раз те самые графики, которые демонстрируют как имея несколько свободных ядер, венда перекидывает поток жрущий 100% времени одного ядра между ядрами. Теоретическая часть -- это объяснение происходящего с отсылками к устройству планировщика задач венды. >> Я отмечу, что ты не предлагаешь никакой альтернативы им. > В моём же сообщении 3.61 я сразу написал: >> Советую почитать Windows Internals, например 7-ое издание. Иди ты с этой альтернативой знаешь куда? Мне венда не въелась совершенно, из любопытства я могу почитать обсуждаемую статью, чтобы узнать немного о том, как она работает. Но всякие вендовс интерналс я прекратил читать лет двадцать назад, когда заглянул в linux и увидел, что здесь можно читать не дурацкую писанину технических писателей, а непосредственно исходный код. >> Важно надуваешь щёки, пытаясь выглядеть знатоком ядра Windows и планировщика в нём, но объяснить поведение ядра, продемонстрированное графиками, тебе пока не удаётся. > Я не знаток конечно, я лишь консультирую по NT Internals. Лол. Мне нравятся твои консультации: "идите и почитайте windows internals". Тебе за такие советы реально кто-то платит денег? Вообще, насколько я понимаю задачу консультирования, в ней очень важно иметь навык понимания собеседника, потому как ежели консультант не в состоянии понять того, кого он консультирует, то он действительно никогда не сможет дать совета лучше, чем "RTFM". Второй важный навык -- это умение объяснять и отвечать на вопросы. Ты здесь и сейчас продемонстрировал, что ни один из этих навыков тебе недоступен. Я чёрть-его-знает-сколько времени выуживал из тебя ответы на простые вопросы, получая ненужные мне ответы на вопросы, которых я не задавал. Как ты вообще работаешь консультантом при этом? В качество профориентационного совета: тебе лучше податься в маркетинг или в политику -- там как раз очень полезно умение уходить от прямых вопросов, создавая при этом впечатление открытости и готовности развёрнуто отвечать на любые вопросы. > Зачем я > должен объяснять поведение планировщика рандомному человеку, когда этот рандомный человек, > если он захочет конечно, может прочитать замечательную книгу от настоящих знатоков? > Смысл пересказывать содержимое книги? Мне не нужно содержимое книги, мне хочется знать короткое объяснение простому феномену: почему венда жонглирует потоком между свободными ядрами, хотя оно могло бы оставить его крутится на одном ядре.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


	358. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 07-Янв-20, 21:09
	Я уже начинаю уставать от этого диалога, если честно. Я не говорю, что автор графика накосячил (вероятнее всего ошибок в графике нет, хотя к нему не хватает комментариев). Я утверждаю, что подобное поведение (перескакивание потока с ядра на ядро) легко объясняется без пинков в сторону "примитивности" планировщика. Я предоставляю очень вероятный сценарий (в сообщении 11.318), в котором график абсолютно корректен. Дополню сценарий дополнительными комментариями: Планировщик, запускаемый на только что освободившемся ядре 2 (которое могло выполнять очень лёгкую работу, и/или в конце добровольно отдавать управление, поэтому на графике, даже если это график полной нагрузки каждого ядра, оно могло быть любым кол-вом процентов), решает забрать нашу сложную ("single-threaded workload", поток A из 11.318) работу у ядра 0, которая недавно была вытеснена другим потоком по причине истечения кванта времени (SMT, preemptive scheduling). Это позволяет избежать простаивания на любом ядре в любой момент времени (что, конечно, хорошо), но да, это действительно перекидывание потока с ядра на ядро. Да, оно ведёт к L1 cache miss, но есть хороший шанс (обеспеченный алгоритмически, ибо планировщик Windows знает про сеты процессоров и NUMA ноды), что L2 или L3 всё ещё содержат нужные данные. Подчеркну, что ядро 0, отдав наш поток A, могло начать заниматься чем угодно (любая ненулевая нагрузка любой сложности), но это должно было бы произойти (если есть хотя бы один ещё поток в очереди), ядро должно хотя бы иногда переключать контекст (опять, кванты времени). А ядро 2 могло в любой момент (разумеется, после того, как ядро 0 переключилась с потока А) украсть поток A, чтобы не простаивать. Объективно, это позволяет эффективнее использовать все ядра. В статье же, по незнанию автора (статьи, ибо автор статьи и графика может не совпадать) этот эффект истолковывается иначе (и делаются неверные выводы), якобы ядро 2 крадёт поток A у ядра 0 только потому, что оно освободилось (в реальности ядро 0 просто отключилось от потока A по расписанию, и начало другую работу; если другой работы бы не было, планировщик продлил бы т.н. Quantum Target и вернул управление потоку A). Утверждая про некорректное истолкование, я напрямую опираюсь на чётко описанный материал в самой авторитетной технической книге по внутренностям Windows.
	Ответить \| Правка \| К родителю #354 \| Наверх \| Cообщить модератору


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


	374. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."	+/–
	Сообщение от Аноним (26), 08-Янв-20, 10:55
	> Да, тогда когда занятых работой потоков больше чем ядер. Это практически всегда так. На моём домашнем десктопе с 6 логическими ядрами, даже с незапущенным IIS и SQL Server, порядка 240 процессов и 4300 потоков. 0% ни на одно ядро я никогда не наблюдаю. > Ему бы следовало мониторить активность задач, и заметить, что одна задача серьёзно занята чем-то и хочет сожрать столько процессорных квантов, сколько возможно, Угу, он это и делает. В Windows Server базовый квант времени (Quantum Reset) в 4 раза дольше, чем в Windows, специально чтобы снизить количество переключений контекста, но и в клиентских редакциях можно включить такой квант. В клиентских редакциях настоящий квант времени зависит от типа процесса: foreground/background, что тоже может продлевать квант времени. Также есть механизм Priority Boost, но он зависит от конкретной "single-threaded workload". Когда заканчивается квант времени, почти всегда будет использован механизм, который позволяет просто продлить квант времени. Можно повысить приоритет (понизить niceness в Linux), тогда переключение потока на ядре будет ещё реже. > суммарная производительность остальных ядер более чем в 100 раз больше, чем требуется остальным задачам Очень опасное наблюдение, которое целиком опирается на неизменность нагрузки потоков (что, вообще говоря, очень большая редкость). Планировщик Windows записывает историю нагрузки, и использует её, но не на горячем пути планировщика, а в более редких/сложных ситуациях (см. далее). > шедулить остальные задачи по свободным ядрам Так и происходит, это свободные ядра сами делают (планировщик, запускаемый в их контексте). Перекидывание может произойти в редком случае: все остальные потоки приоритета потока A и выше не готовы к выполнению. Чем "дальше" два ядра, тем меньше вероятность перекидывания (т.к. планировщик знает про конфигурацию ядер и итеративно расширяет поиск готовых к исполнению потоков, но до определённого порога, обычно границей является NUMA нода). Как видно из того же графика (опять, на нём нет даже масштаба времени), перекидывание практически всегда происходит между двумя (редко - тремя) ядрами (а в Zen 2 каждый CCX содержит 4 ядра!). --- Почитал я про стандартный CFS (опирался на Wikipedia, https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-de.../ и на https://opensource.com/article/19/2/fair-scheduling-linux). Ни в коей мере не утверждаю правильность понимания, но следующий набор замечаний. > The CFS scheduler has a target latency, which is the minimum amount of time—idealized to an infinitely small duration—required for every runnable task to get at least one turn on the processor. > Of course, an idealized infinitely small duration must be approximated in the real world, and the default approximation is 20ms. Each runnable task then gets a 1/N slice of the target latency, where N is the number of tasks. Немного (сильно) противоречит утверждению: > сильно занятая задача будет "захватывать" ядро на несколько секунд за раз, а не на 40 миллисекунд в среднем. Или это про то, что CFS будет всегда возвращать управление "сильно занятой задаче"? Но всё равно, что с остальными потоками в очереди? Никогда не получат ядро? Далее вводится очень разумный концепт minimum granularity, затем знакомый термин virtual runtime (vruntime) (в Windows эта метрика более чёткая, в плане, на пару счётчиков больше). > Suppose task T1 has run for its weighted 1/N slice, and runnable task T2 currently has the lowest virtual runtime (vruntime) among the tasks contending for the processor. The vruntime records, in nanoseconds, how long a task has run on the processor. In this case, T1 would be preempted in favor of T2. > The scheduler tracks the vruntime for all tasks, runnable and blocked. The lower a task's vruntime, the more deserving the task is for time on the processor. CFS accordingly moves low-vruntime tasks towards the front of the scheduling line. Details are forthcoming because the line is implemented as a tree, not a list. Но ведь это означает, что та самая "single-threaded workload" будет иметь очень большой vruntime и всегда оказываться далеко в "очереди" (которая на самом деле дерево) на исполнение, т.е. она всегда будет уступать более лёгким/быстрым (термин мой) потокам. Не проблема, но интересное замечание. > Yet configurable scheduling domains can be used to group processors for load balancing or even segregation. If several processors share the same scheduling policy, then load balancing among them is an option; if a particular processor has a scheduling policy different from the others, then this processor would be segregated from the others with respect to scheduling. В планировщике Windows это называется processor package, так что это знакомо. Затем я открываю статью "The Linux Scheduler: a Decade of Wasted Cores", патчи из которой, как я слышал, были приняты в планировщик несколько лет назад. Интересный материал, затем я дохожу до этого момента: > Now we have a new problem of balancing work across multiple runqueues. > Suppose that one queue has one low-priority thread and another has ten high-priority threads. > We could have each core check not only its runqueue but also the queues of other cores, but this would defeat the purpose of per-core runqueues. Вот, серьёзное алгоритмическое отличие от планировщика Windows. Планировщик Windows полезет в очереди других ядер в порядке удалённости от текущего. В то время как CFS: > Therefore, what Linux and most other schedulers do is periodically run a load-balancing algorithm that will keep the queues roughly balanced. > Since load balancing is expensive the scheduler tries not to do it more often than is absolutely necessary. In addition to periodic load-balancing therefore, the scheduler can also trigger emergency load balancing when a core becomes idle. Как я понимаю, Windows предпочитает балансировать нагрузку "здесь и сейчас", когда ядро готово войти в состояние простоя, а CFS выделяет это в отдельную регулярно запускающуюся рутину (с возможностью экстренного запуска как в Windows). Сравнивать лучше/хуже не буду, но отмечу, что подход CFS более предсказуем, в то время как планировщик Windows почти* всегда работает в контексте "надо прямо сейчас решить что дальше делать". почти* - есть например отдельный алгоритм по борьбе с CPU Starvation и priority inversion, который работает вне контекста конкретного потока, но он асинхронный и работает как "консультант", рекомендуя правки к финальному решению планировщика Windows, опираясь на историю нагрузки каждого потока. Сделаю вывод из прочитанного: Linux предпочитает простаивание ядер (если даже load balancing и перекинет все потоки кроме потока A на другие ядра), но удерживает (если load balancing так решит) потоки в пределах одной runqueue. Windows действует "жадно", решая, что лучше в каждый момент (но опираясь на историю в некоторых случаях), что может приводить к краже потоков, если эта кража дешёвая (внутри одного processor package, ибо более широкие поиски задействуются очень редко), а другой работы соответствующего приоритета нет. Это иногда случающееся перекидывание потоков имеет обоснование (снижение количества простаивающих ядер), но cache miss'ы могут случаться чаще (они весьма вероятны и на CFS, ибо если load balancing оставит хотя бы один другой поток на ядре, где выполняется поток A - точно так же будет борьба за L1 и L2 в течение каждого target granularity, а отношение ядер/потоков явно не в пользу ядер).
	Ответить \| Правка \| К родителю #370 \| Наверх \| Cообщить модератору