The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

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

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


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

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

Важная деталь.

> сам Линус
> говорит, что spin lock-и использовать нельзя.

"использовать с большой осторожностью и полностью разбираясь в деталях"

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

29. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +4 +/
Сообщение от anonymous (??), 06-Янв-20, 11:32 
>> сам Линус
>> говорит, что spin lock-и использовать нельзя.
>
> "использовать с большой осторожностью и полностью разбираясь в деталях"

Если быть конкретнее, то Линус говорит:

> Or, if you really want to use use spinlocks (hint: you don't), make sure that while you hold the lock, you're not getting scheduled away. You need to use a realtime scheduler for that

То есть с его точки зрения, я всё это время использовал spinlock-и неправильно. И я не говорю, что Линус не прав. Я лишь говорю, что это неожиданно (и является пищей для размышления). Хотя, мне всё же кажется, что область применения spinlock-ов шире, чем обозначил Линус, ибо успех на коротких lock-ах много раз переподтверждался на разных платформах (если они не одноядерные) и без realtime scheduling-а. То есть да, есть риск, что scheduler переключит поток, в котором я собирался разблокировать spin lock, но если lock достаточно короткий, то такое бывает очень редко, и в среднем будет (и есть) сильный выигрыш. Не очень понимаю, почему Линус так сказал...

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

31. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +6 +/
Сообщение от anonymous (??), 06-Янв-20, 11:41 
> то такое бывает очень редко

Из-за этого редко некоторые игры на Stadia лагают, поэтому Линус ему так и ответил что он **** и не разбирается в том, как работает spinlock на ОС без realtime scheduling-а. Вот и весь посыл, а ещё он сказал что всё что намерил разработчик - мусор. И правильно сказал, ибо в контексте, в котором пишет разработчик Stadia, оно мусором и является.

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

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

36. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +5 +/
Сообщение от Аноним (6), 06-Янв-20, 11:53 
> я всё это время использовал spinlock-и неправильно

Не так что бы всё. Точнее можно оценить из соотношения времён взятия спинлока и длительности кванта планировщика.

> и является пищей для размышления

ИМХО именно с такой целью Линус и высказался.

Это примерно как в детстве учат: "не суй пальцы в розетку". Потом преподают закон Ома и так далее. Кто-то идёт в электрики, кто-то -- атомные электростанции строить. А некоторым и к старости нечего пальцы в розетку сувать.

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

120. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Янв-20, 15:14 
> Это примерно как в детстве учат: "не суй пальцы в розетку".

Ой да.  Единственно что дополню: по упорным типа меня лучше работало "сунешь пальцы в розетку -- долбанёт так, что мало не покажется".  Чтоб когда всё-таки долбанёт, было над чем задуматься и попробовать выяснить, а они-то откуда заранее знали...

То есть от неоправданных догматов переходить к пониманию происходящего.

PS: а то розетка-то может быть обесточенной, "догмат" пострадает (и в следующий раз может не спасти своего носителя), поскольку был неверен изначально -- а понимание подскажет, почему пронесло.

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

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

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

--

Попал мне камушек в сандаль. Я рукой об эту штуку опёрся, ногой потряс, и тут этот ошалелый меня как огреет доской!

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

417. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от Cadet (?), 13-Янв-20, 19:00 
>в детстве учат: "не суй пальцы в розетку"

А я сунул. Точнее за оголенные провода специально взялся. Нехило так потом руку колотило.

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

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

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

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

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

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

На коротких спинлоках статистически ты выигрываешь. Но изредка возможны (относительно большие) задержки, в тех случаях, когда твой спинлок был прерван перепланировкой. Тебя это устраивает, а игроделов - нет.

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

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

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

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

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

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

Эта статья вызывает мегатонны фейспалмов и показывает, что бестолковость Торвальдса лишь немного меньше бестолковости среднего опеннетовского анонима.

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

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

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

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

Строго говоря, Линус говорит, что их ненужно использовать, если вы точно не знаете как надо, чтобы было не больно, а то будет ай-ай-ай!

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

351. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +1 +/
Сообщение от Сергейemail (??), 07-Янв-20, 18:07 
> прирост в производительности

This. У него "прирост производительности" aka "Average test duration" на спинлоках в линуксе тоже виден, почти на всех шедулерах. Но его же интересует задержка, aka "Four longest idle times" - что даже не 99 перцентиль.

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

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

398. "Линус Торвальдс опроверг проблемы с планировщиком задач, всп..."  +/
Сообщение от КО (?), 09-Янв-20, 10:27 
>Если чувака интересует только задержка,

А всякие starvation и проблемы с перегруженным процессором его не колеблют, то да чем проще цикл spinlock - тем эффективней. Если рояет что-то другое, то и инструмент надо выбирать другой.

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

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру