Привет,

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

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

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

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

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


5 січня 2018, 15:46:52, від "Mykola Ulianytskyi" <lystor@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>.