[uanog] Project Zero: В Новый Год - с новым багом!

Vladimir Sharun vladimir.sharun at ukr.net
Fri Jan 5 16:23:14 EET 2018


Привет,



Ответ Интела весьма честен:



Вопреки некоторым отчётам, любое влияние на производительность зависит
от конкретной рабочей нагрузки и для среднего пользователя влияние не
должно быть значительным и со временем будет минимизировано. 


Т.е. для SQL, который гигабайтами таскает из кэша ФС - будет ой-ой (Постгрес, привет!), в то же самое время например Innodb почти не пострадает из-за того, что самостоятельно менеджит память. Твой случай с dd как раз очень показателен тем, что происходит перетаскивание из одного ведра в другое, а выбранный блок сайз - нереально плОх. Попробуй реальные размеры - 32к и больше, там падение будет не так заметно. 



Где-то похожая тема была, когда у нас 32бит код работал в 64бит системе - враппер сисколлов конкретно так воровал на 512к блоках, и был уже практически незаметен на 16к.



Если ты не пускаешь на свои сервера "не своих", то и проблемы нет. Хостерам и VDS'никам придётся попотеть, да.





5 січня 2018, 15:46:52, від "Mykola Ulianytskyi" <lystor at gmail.com>:


https://www.overclockers.ru/hardnews/88813/oficialnoe-zayavlenie-intel-po-povodu-obnaruzhennoj-kriticheskoj-uyazvimosti.html


---
> компания считает, что "заплатка", которая исправит данный "недостаток" не должна повлиять на производительность систем.

Выключен PTI:
# dd if=/dev/zero of=xxx bs=512 count=5000000
1.1 GB/s

Включен PTI:
# dd if=/dev/zero of=xxx bs=512 count=5000000
520 MB/s

<censored>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20180105/7bc04e8f/attachment-0001.html>


More information about the uanog mailing list