Однако, реальный прирост производительности на фряхе )
По сравнению с APC — порядка 20-30+% cpu экономится.
И на ядро тоже загрузка раза в два упала.
Плюс php-fpm перестал крешится, как это было регулярно с APC.
Т.е. не владельцев аппаратных файрволов, которых 99+%, в расчет можно и не брать? Проекты у них не серьезные, чего париться?
Никому не приятно видеть такие неожиданности, но между «бегать в горячке и срочно искать решение, типа установки железного файрвола (ещё нужно, чтобы он сам не использовал эту 82574L), или замены карточки (или всего сервера)» и «загрузиться по PXE и обновить прошивку за пару минут» я предпочту второе.
Что-то мне подсказывает, что для некоторых радость этого понимания быстро перекроется огорчением от возросшей волны таких падений, и уж это огорчение будет ещё многократно усиленно необходимостью срочно искать новую сетевуху и дауном на время разборки сервера…
А при чем здесь это? Речь идет о том, что как и при любой другой dos уязвимости, нашедший эту уязвимость обычно дает время вендору выпустить фикс, а не бежит хвастаться налево и направо, практически выдав готовый эксплоит. Задайте лучше вопрос владельцам таких серверов: «готовы ли они к возможным dos-атакам на их ресурсы при отсутствии свежих прошивок»?
Я не в курсе деталей, возможно, Intel была уведомлена уже давно, тогда никаких претензий. Но в таком случае об этом стоило написать в новости, а то иначе возникают такие вопросы, как у меня.
P.S. у Supermicro отличные мамки, а у Intel — лучшие сетевые карты и драйвера к ним (imho). И в данном инциденте у меня претензии не только к Intel, но и к тем людям (вполне возможно, что сам Кристиан к этому непричастен), которые дали в руки кулхацкерам новую игрушку.
Мне интересно было бы услышать более развернутое мнение от минусующих граждан, чем просто увидеть красную цифру с черточкой. Разумеется, если они не протестуют против этической составляющей в принципе )
Кстати, вообще-то неэтично выпускать такую новость в паблик до того, как будет готова новая прошивка. Ведь соорудить эксплоит для этой уязвимости — дело нескольких десятков минут. Тем более что карточка очень популярная.
На подавляющем большинстве 00:25:90 (причем такое начало есть и на других картах, например 82579LM), но на некоторых встречаются и 00:30:48 (а такой мак имеют очень много разных интеловых карт: Intel PRO/1000 EB, 80003ES2LAN, 82573E,..)
Такой груз лежит под ногами. Пару десятков кубометров грунта — и вот вам 60т.
Вопрос в другом — зачем сложности с перекачкой и сливом воды, регулированием кол-ва гелия в реалтайме etc, когда для фиксации грузовой платформы её достаточно просто ещё сильнее догрузить в припаркованном положении. Такое впечатление, что они пытаются оставить дирижабль висящим в воздухе во время разгрузки, но зачем ??
Гм, а что за сложности такие с разгрузкой?
Опустил дирижабль, чтобы он на земле стоял, заехал в грузовой отсек машинкой с 3т кирпичей, и можно спокойно разгружать 3т груза — дирижабль никуда не улетит.
И много они наторгуют, интересно? Продавать контент по рыночным ценам не получится — лучше купить у студии-владельца. Даже если удастся продать по не рыночным — так все равно контент лицензионным не станет после этого, кому такое надо?
>Но как отреплеить кэш?
Если озаботиться заранее, то нет проблем. Периодически в журнал кеша (не в памяти, а на ssd) дописывать, какие dirty-блоки уже записаны на диск. После ребута можно поднять этот журнал, поднять список блоков в очереди на запись, и дописать те, которые по журналу ещё не записаны.
>Как драйвер кэша поймет, что нужно реплеить, если про файлуху и ее логику он не знает ничего?
А ему и не надо ничего знать про fs. Достаточно дописать недописанные данные (см. выше), и отдать устройство fs, а она посмотрит и сделает весь recovery что нужно. Т.е. fs и знать не будет, что был write-back кеш, для нее будет выглядеть что просто запись оборвалась с какого-то момента (а именно, с того момента, когда данные ещё не записались на ssd).
С отрицательной температурой освоились, не за горами отрицательная энергия, за ней масса…
А там, глядишь, и вселенная окажется голограммой, а сознание окажется первичнее материи…
За ссылку спасибо. Хоть я и не под виндой программирую, но немного интересно, что и как на другой стороне происходит.
Согласен, что дискуссию можно завершать, ведь генерация ПСЧ действительно происходит быстро и не должна включать в себя переключение контекста, да и изначально мой месседж состоял в том что инструментарий для программисто надо готовить тщательно, а не так чтобы его потом ещё напильником надо было дорабатывать.
Тем не менее, есть один момент касательно
Spinlock вам ничем не поможет. Его взятие будет ещё дороже чем Monitor.Enter/Exit
SpinLock and SpinWait are structs and not classes! This design decision was an extreme optimization technique to avoid the cost of indirection and garbage collection.
The SpinLock struct lets you lock without incurring the cost of a context switch, at the expense of keeping a thread spinning (uselessly busy).
Я уже упоминал постом выше про свойства спинлока — это самый оптимизированный способ залочить очень короткую операцию, по сравнению с которой любые другие способы блокировки приведут к оверхеду, часто на порядки большему, чем собственно операция. Высокой конкуренции он как раз очень-очень не любит — с ним надо обращаться весьма аккуратно, в частности, лочить очень короткие операции.
В частности, если лочить весь процесс генерации ПСЧ, от взятия текущего сида до его обновления, то это ограничит производительность rand() максимум одним ядром минус оверхед (ок, пусть даже десятки процентов). Но я не представляю себе ситуации, где может потребоваться большая производительность для rand(), так что сделать его thread-safe все-таки стоило бы из коробки )
1. Это везде так, ведь надо шедулеру управление передать и усыпить тред. Но это самый тяжелый случай, когда лок занят надолго, на блокирующейся операции например, или долгих вычислениях…
2. Гм, у Вас неверное представление о spinlock-ах — это самые дешевые (в плане взятия) и быстрые (в плане времени на взятие/освобождение) локи, но они создают большую дополнительную нагрузку на cpu в тех тредах, которые пытаются захватить заблокированный ресурс, поэтому должны использоваться недолго. Например, при обновлении переменной.
3. Thread-safety сегодня — насущная необходимость, и уже много ресурсов было брошено на оптимизацию этого вопроса, так что не все так страшно, как было 10 лет назад.
Слово spinlock вам ничего не говорит? Мьютексы, они, знаете ли, очень разные бывают ) Правда, не знаю особенности реализации блокировок в .NET, поэтому не стану утверждать, что на этой платформе thread-safety реализуется без больших накладных расходов.
Зачем придираться к словам? Разумеется у генератора будет стартовое состояние после создания, но я ведь имел ввиду «инициализацию» как подготовку к выдаче различающихся псевдослучайных чисел, а не одного и того же потока для каждого запуска программы. Ведь в 99.(9)% случаев программисту надо именно просто какое-то похожее на случайное число, и крайне желательно чтобы оно было НЕ предсказуемым. А srand() то как раз сделали для того чтобы получать ПРЕДСКАЗУЕМЫЙ поток, а вовсе не для тех, кого он не устраивает )
Да прямо уж на порядок. )) Звучит страшно, а давайте аккуратно проанализируем? Для одного потока блокиратор только один, а значит конкуренции за мютекс ему ждать неоткуда — так что тут оверхед микродоли процента. Для нескольких потоков — необходимо лочить сид чтобы им не воспользовался паралельный поток для получения такого же числа. Можно лочить втупую, до тех пор пока не посчитаем новое значение, а можно в умную, проинкрементив сид и отпустив лок (чтобы паралельный поток получил отличающееся число без ожидания мютекса), и потом проапдейтить сид, когда новое значение будет высчитано (тут и лок без необходимости). Опять оверхед очень и очень далек от «возросшего на порядок времени»…
>Вы хотите сказать — добавить им необходимости выискивать неочевидные ошибки?
Вы, очевидно, не пытаетесь понять мою мысль. Если программисту нужно случайное непредсказуемое число, то в чем вообще может произойти ошибка, если он его получит легко и без напряга?
>И потому для реальных целей малоприменим.
Вдумайтесь в свои слова ) Если реализовано малоприменимое решение, вместо применимого, то налицо архитектурный дефект.
А не кажется ли Вам, что в rand() можно встроить проверку был ли инициализирован srand()? И ещё сделать его сразу threadsafe? Т.е. избавить сотни тысяч! программистов от необходимости тратить миллионы человеко-часов на всю эту рутину и избавить их от необходимости выискивать неочевидные ошибки? А для тех, кому действительно надо, — оставить возможность при необходимости покопаться под капотом, как-то выставить начальное состояние принудительно или ещё что-то, для тех же тестов.
А почему Вы решили, что я имел в виду алгоритмическую сложность?
r = rand(1);
одна строчка, одно действие — в переменную r попадает (псевдо)случайное значение в диапазоне [0..1). Если нет никаких подводных камней вроде проблем с инициализацией и тредовой безопасностью, можно спокойно программировать дальше то что задумал, и не отвлекаться на низкоуровневые вещи. Я ж сравнение с ассемблером не зря упомянул.
Казалось бы, времена ассемблера давно прошли… Ан нет, все ещё приходится писать страницы кода чтобы получить простой тривиальный результат, вроде вычисления случайного числа. Платформы наращивают номера с все убыстряющимся темпом, а программисту почему-то не сильно легчает от этого. Может не в том направлении шагаем?
По сравнению с APC — порядка 20-30+% cpu экономится.
И на ядро тоже загрузка раза в два упала.
Плюс php-fpm перестал крешится, как это было регулярно с APC.
Пока что только положительные впечатления.
Никому не приятно видеть такие неожиданности, но между «бегать в горячке и срочно искать решение, типа установки железного файрвола (ещё нужно, чтобы он сам не использовал эту 82574L), или замены карточки (или всего сервера)» и «загрузиться по PXE и обновить прошивку за пару минут» я предпочту второе.
Я не в курсе деталей, возможно, Intel была уведомлена уже давно, тогда никаких претензий. Но в таком случае об этом стоило написать в новости, а то иначе возникают такие вопросы, как у меня.
P.S. у Supermicro отличные мамки, а у Intel — лучшие сетевые карты и драйвера к ним (imho). И в данном инциденте у меня претензии не только к Intel, но и к тем людям (вполне возможно, что сам Кристиан к этому непричастен), которые дали в руки кулхацкерам новую игрушку.
82574L весьма популярная карта на мамках Supermicro
Вопрос в другом — зачем сложности с перекачкой и сливом воды, регулированием кол-ва гелия в реалтайме etc, когда для фиксации грузовой платформы её достаточно просто ещё сильнее догрузить в припаркованном положении. Такое впечатление, что они пытаются оставить дирижабль висящим в воздухе во время разгрузки, но зачем ??
Опустил дирижабль, чтобы он на земле стоял, заехал в грузовой отсек машинкой с 3т кирпичей, и можно спокойно разгружать 3т груза — дирижабль никуда не улетит.
Если озаботиться заранее, то нет проблем. Периодически в журнал кеша (не в памяти, а на ssd) дописывать, какие dirty-блоки уже записаны на диск. После ребута можно поднять этот журнал, поднять список блоков в очереди на запись, и дописать те, которые по журналу ещё не записаны.
>Как драйвер кэша поймет, что нужно реплеить, если про файлуху и ее логику он не знает ничего?
А ему и не надо ничего знать про fs. Достаточно дописать недописанные данные (см. выше), и отдать устройство fs, а она посмотрит и сделает весь recovery что нужно. Т.е. fs и знать не будет, что был write-back кеш, для нее будет выглядеть что просто запись оборвалась с какого-то момента (а именно, с того момента, когда данные ещё не записались на ssd).
А там, глядишь, и вселенная окажется голограммой, а сознание окажется первичнее материи…
Согласен, что дискуссию можно завершать, ведь генерация ПСЧ действительно происходит быстро и не должна включать в себя переключение контекста, да и изначально мой месседж состоял в том что инструментарий для программисто надо готовить тщательно, а не так чтобы его потом ещё напильником надо было дорабатывать.
Тем не менее, есть один момент касательно
Смотрим http://www.albahari.com/threading/part5.aspx#_SpinLock_and_SpinWait:
Я уже упоминал постом выше про свойства спинлока — это самый оптимизированный способ залочить очень короткую операцию, по сравнению с которой любые другие способы блокировки приведут к оверхеду, часто на порядки большему, чем собственно операция. Высокой конкуренции он как раз очень-очень не любит — с ним надо обращаться весьма аккуратно, в частности, лочить очень короткие операции.
В частности, если лочить весь процесс генерации ПСЧ, от взятия текущего сида до его обновления, то это ограничит производительность rand() максимум одним ядром минус оверхед (ок, пусть даже десятки процентов). Но я не представляю себе ситуации, где может потребоваться большая производительность для rand(), так что сделать его thread-safe все-таки стоило бы из коробки )
2. Гм, у Вас неверное представление о spinlock-ах — это самые дешевые (в плане взятия) и быстрые (в плане времени на взятие/освобождение) локи, но они создают большую дополнительную нагрузку на cpu в тех тредах, которые пытаются захватить заблокированный ресурс, поэтому должны использоваться недолго. Например, при обновлении переменной.
3. Thread-safety сегодня — насущная необходимость, и уже много ресурсов было брошено на оптимизацию этого вопроса, так что не все так страшно, как было 10 лет назад.
Да прямо уж на порядок. )) Звучит страшно, а давайте аккуратно проанализируем? Для одного потока блокиратор только один, а значит конкуренции за мютекс ему ждать неоткуда — так что тут оверхед микродоли процента. Для нескольких потоков — необходимо лочить сид чтобы им не воспользовался паралельный поток для получения такого же числа. Можно лочить втупую, до тех пор пока не посчитаем новое значение, а можно в умную, проинкрементив сид и отпустив лок (чтобы паралельный поток получил отличающееся число без ожидания мютекса), и потом проапдейтить сид, когда новое значение будет высчитано (тут и лок без необходимости). Опять оверхед очень и очень далек от «возросшего на порядок времени»…
>Вы хотите сказать — добавить им необходимости выискивать неочевидные ошибки?
Вы, очевидно, не пытаетесь понять мою мысль. Если программисту нужно случайное непредсказуемое число, то в чем вообще может произойти ошибка, если он его получит легко и без напряга?
>И потому для реальных целей малоприменим.
Вдумайтесь в свои слова ) Если реализовано малоприменимое решение, вместо применимого, то налицо архитектурный дефект.
r = rand(1);
одна строчка, одно действие — в переменную r попадает (псевдо)случайное значение в диапазоне [0..1). Если нет никаких подводных камней вроде проблем с инициализацией и тредовой безопасностью, можно спокойно программировать дальше то что задумал, и не отвлекаться на низкоуровневые вещи. Я ж сравнение с ассемблером не зря упомянул.