| |
| 2.10, Петр А (?), 00:32, 06/01/2018 [^] [^^] [^^^] [ответить]
| –17 +/– | |
>> Стало быть, драмы не будет.
Драма есть уже — вишь, минусаторы страдают.
Проблема с обеими «уязвимостями» возникает в одной ситуации — когда ПАРАЛЛЕЛЬНОЕ ИСПОЛНЕНИЕ кода оформляется не ручками, с контролем гонок и памяти на уровне исходников, а «хреньворками».
146% посетителям сего богоспасаемого места — это, как зайцу стоп-сигнал.
| | |
| |
| 3.13, h31 (ok), 03:22, 06/01/2018 [^] [^^] [^^^] [ответить]
| +12 +/– |
 Давай, оформляй всю необходимую параллельность ручками. Бери исходники, редактируй, отправляй. А я послежу, чтобы ты "хреньворками" не пользовался.
Для общего развития: спекулятивное выполнение работает на гораздо более низком уровне, чем традиционная многопоточности. С использованием pthreads ты никак не реализуешь спекулятивное выполнение на том уровне, на каком работает процессор, а даже если и сможешь, то накладные расходы на манипуляцию потоками будут гигантскими. Это если говорить про популярные архитектуры ЦПУ, не VLIW.
| | |
|
| 2.37, anomymous (?), 12:25, 06/01/2018 [^] [^^] [^^^] [ответить]
| +9 +/– |
Драма будет, когда эксплоиты начнут работать in the wild - а PoC'и открыты, и начнутся массовые утечки банковских и персональных данных у хомяков. Вот для этой драмы я попкорна купил уже.
| | |
| |
| 3.45, Anonymoustus (ok), 15:26, 06/01/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 У тех банков, которые используют мейнфреймы и неуязвимые by design системы, утечек не будет.
| | |
| |
| 4.55, IB (?), 19:35, 06/01/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Как мэйнфрейм защитит от кражи трояном данных карты с формы при оплате в инет магазине?
Или паролей от Яндекс-кошелька.
Смысл - троян установившийся под юзером может читать данные других юзеров / программ / системы.
| | |
| |
| |
| 6.92, Аноним (-), 15:42, 08/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
увы, какой безопасник признается, что могла и быть утечка, а нерушимая система при легкой секундной мисконфигурации становится оплотом диверсионной работы
| | |
|
| |
| |
| 7.96, Аноним (-), 20:02, 08/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Не у всех остался VMS, а тем более VAX.
в соседней новости из гзипа выкинули поддержку vms, так что на нём уже особо не погзипуешь
| | |
| |
| 8.97, Аноним (-), 20:58, 08/01/2018 [^] [^^] [^^^] [ответить] | +/– | Угу, апдейт для гзипа просто удаляет бинарники gz ungz на этой платформе И заод... текст свёрнут, показать | | |
|
|
|
|
|
| 3.49, леон (?), 17:09, 06/01/2018 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> а PoC'и открыты, и начнутся массовые утечки банковских и персональных данных у хомяков.
Им же нечего скрывать, в чём проблема?
| | |
| 3.72, нах (?), 10:15, 07/01/2018 [^] [^^] [^^^] [ответить] | +/– | как будто для этого нужны были какие-то еще ыксплоиты http www opennet ru ope... большой текст свёрнут, показать | | |
| 3.76, Як (?), 13:47, 07/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Многие почему-то забыли о такой мелочи, как производительность. Хорошо оптимизированный сплоит на ассемблере читает память со скоростью 2 кб/с. Вопрос: с какой скоростью будет читать память сплоит на JS и сколько байт он успеет прочесть, прежде чем пользователь все-таки заметит, что браузер уже несколько часов как отожрал полностью одно ядро?
| | |
| |
| 4.101, лютый жабист__ (?), 07:53, 09/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>прежде чем пользователь все-таки заметит, что браузер уже несколько часов как отожрал полностью одно ядро
По моим наблюдениям, юзер такое не заметит вообще. Даже на ноутбуке, который начинает громче жужать вентилем. А уж производительность вообще не меняется от плюс-минус одно ядро :)
| | |
| 4.103, Джо (?), 09:28, 09/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Насколько я понимаю с такой-же: готовишь js или asm.js такой, которым джитом переводится в требуемый ассемблер и получаешь схожую производительность.
| | |
|
|
|
| 1.2, DiabloPC (ok), 23:32, 05/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +17 +/– |
 > Google ... оценивается как незначительное
А цифры где? А то для гугла и 50% может оказаться "незначительным", кто ж знает что у них там в головах то %)
| | |
| |
| 2.3, Crazy Alex (ok), 23:56, 05/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Где-то попадалось странное - для более старого интеловского процессора замедления почти не было, а для Coffee Lake было существенно сильнее. Но сходу снова не гуглится
| | |
| |
| |
| 4.29, Crazy Alex (ok), 10:46, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Это было что-то англоязычное и там были две конкретные модели процессора - какие-то i7. Ладно, всплывёт если доля истины в этом есть. А если нет - то и чёрт с ним
| | |
| 4.31, Crazy Alex (ok), 10:52, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Если намекали на злонамеренность гугла - то я как раз об обратном, если оно так - то на их процессорном парке и правда не должно было сказаться
| | |
|
| |
| 4.53, Andrey Mitrofanov (?), 18:22, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
> То есть я где-то в другом месте читал, но тут разница хорошо
> видна.
На нём же, родном - https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1
Там был, я ж тоже помню!, пассаж типа "вот на 9700xx ой-ёй-ёй,а на более старом 6800zz почти и не заметно". Теперь такого в статье _нет_.
Микаэль, надо понимать, почитал новости, что оно уже 10-15 лет "того", а не год-два с прошлого Lake-а -- да и исправил уже опубликованного "глубокого анализа".
[I]" [,,,] here are my initial benchmark numbers on two systems. "
" I ran tests on a Core i7 8700K "Coffee Lake" system as well as an older Core i7 6800K "Broadwell E" system [...] "
| | |
|
|
| 2.6, Mike Lee (?), 00:21, 06/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как раз наоборот. Для гугла 50% это тысячи дополнительных ядер. А для большинства незаметно.
| | |
| 2.21, пох (?), 07:20, 06/01/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
цифры - они в индексе. И поэтому инвесторы гугля действительно могут спать спокойно.
Какое количество картонных серверов еще понадобится ввсести дополнительно. чтобы покрыть издержки - им все равно не расскажут (да и не знает никто), и им это неважно.
Статейка написана ровно ради этих индексов - а то после заявлений всяких вредных личностей они что-то нехорошо заворочались.
Ну и да - в очередной раз вспоминая о средней длине члена - grsec меряли (и описали, чем) а гугль - "считает". Но инвесторы (да и индустрия) будут слушать гугля, а не каких-то там.
| | |
|
| |
| 2.20, лютый жабист__ (?), 07:17, 06/01/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Просто GOOGLE использует старое протухшее железо
Да. В google cloud computing все инстансы на древних процах с низкой частотой. Скайлэйк можно выбрать, но далеко не во всех ДЦ.
Кстати, интересно, почему гуголь не использует амд.
| | |
| |
| 3.30, Аноним (-), 10:47, 06/01/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Судя по недавним новостям - интель им по-братски дал кредит под 0% на свои commodity-процы.
А то гляди ка - и Google Project Zero "внезапно" открыл уже известные уязвимости (даже названия присвоили!), и Google Cloud зашевелились (это вообще кто такие?). А главное - сколько шуму: PR-война в самом разгаре. Учитывая, за кем сейчас преимущество в вычислительных мощностях, неудивительно, что гугловцы полируют штеудовский сексуальный орган - чай не дураки, рубить сук на котором сидят.
| | |
| 3.98, ACCA (ok), 22:42, 08/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Исторически так сложилось. Pentium III имел самое низкое энергопотребление на операцию.
200 млн. процессоров, экономия на каждом по 3-5-10 Вт...
Походу эти Pentium III так и работают там.
| | |
|
| 2.42, Аноним (-), 14:32, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>Просто GOOGLE использует старое протухшее железо
Проблема появилась с появлением у Штеуда технологии предсказания ветвлений, т.е. в самых первых Пнях.
| | |
|
| 1.7, яя (?), 00:21, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
я ставить эту херню не буду. надеюсь будет опция в ядре чтоб не вкомпиливать.
| | |
| 1.9, Аноним (-), 00:31, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Эммм, посмотрел, нихрена не понял. Они там пишут свой собственный вариант инструкции call? Как эта магия retpoline работает вообще? Оно защищает если ядро скомпилировали патченным компилятором, который заменяет везде call на какую-то последовательность команд, но в программе пользовательской может быть не заменено же? Хотя, наверное, можно браузер перекомпилять и хотя бы за javascript-эксплоиты быть спокойными...
| | |
| |
| 2.12, asdasdasd (?), 02:44, 06/01/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
Хз как оно работает, но оно не собирается. Собрал их GCC retpoline, собирал ядро и получил кучу undefined reference -_-
| | |
| 2.50, Crazy Alex (ok), 17:33, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да, оно защищает конкретно ядро. Насколько я понимаю, Сама уязвимость позволяет дотянуться какому-то недоверенному коду до данных в том же процессе, в котором он исполняется, так что, в общем-то, патчить надо только тот софт, где такое возможно. Браузер - первый кандидат... но загрублённые таймеры мне как-то больше по вкусу, браузеры и так тормозить умеют слишком хорошо.
| | |
|
| |
| 2.22, пох (?), 07:23, 06/01/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Осталось дождаться фиксов от Intel и AMD.
ну, здоровенный апдейт микрокода в rhel три дня назад приполз. Что он на самом деле там фиксит (и не надо ли, кстати, его откатить, если не хочешь потери производительности даже с непатченным ведром) - разумеется, большая коммерческая тайна.
| | |
| |
| 3.108, Аноним (-), 14:38, 09/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>если не хочешь потери производительности даже с непатченным ведром
Да куй с ней вообще, с производительностью. Вы чо, совсем все нищeброды на третьепнях, штoле? Лучше подумайте, какого западла они могли туда под шумок напихать. И не был ли этот "подшумок" для того и организован.
| | |
|
|
| |
| 2.17, Аноним (-), 06:16, 06/01/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Он понимает, что intel не будет возвращать серверную продукцию за 10-лет по всему земному шару вендорам.
| | |
|
| 1.18, Аноним (-), 06:59, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Пишут, что не сильно замедляет, но сильно греются процессоры от этих патчей.
| | |
| |
| 2.23, Аноним (-), 08:28, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Пишут, что не сильно замедляет, но сильно греются процессоры от этих патчей.
От двойного переключения контекста ЦПУ, больше переключения богу пустынного кремния!!!
| | |
|
| 1.24, Аноним (-), 08:33, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
сговор гигантов, нужно поднять продажи, а может сам патч и есть бэкдор мазафака
| | |
| 1.26, Геймер (?), 08:50, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Костыли это, а не патчи. Потому что эти "патчи" реально нихрена ничего не патчат. И то, что программно отключается, может обратно программно включаться. Особенно это касается "патчей" Микрософт, где однозначно оставлена недокументируемая лазейка кому-надо включать мельтдаун, а когда надо отключать.
Производительность - вопрос вторичный. Потому что процессоры гнилые на уровне их архитекторов - это даже не брак производства. И все последние 20 лет впаривали по сути 286 процессоры с имитацией многозадачности только многогигагерцовые и многядерные.
Хотя начиная с 386 и заканчивая Пентиум Про плюс Сайрикс и Виа вполне возможно были настоящие многозадачники.
А хипстерня сожрала Интел МЕ, сожрёт и мельтдаун. Лишь бы только производительность в игрушках не снизилась.
| | |
| |
| 2.27, Аноним (-), 09:00, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> Особенно это касается "патчей" Микрософт, где однозначно оставлена недокументируемая
> лазейка кому-надо включать мельтдаун, а когда надо отключать.
> Производительность - вопрос вторичный. Потому что процессоры гнилые на уровне их архитекторов
> - это даже не брак производства. И все последние 20 лет
> впаривали по сути 286 процессоры с имитацией многозадачности только многогигагерцовые
> и многядерные.
> Хотя начиная с 386 и заканчивая Пентиум Про плюс Сайрикс и Виа
> вполне возможно были настоящие многозадачники.
> А хипстерня сожрала Интел МЕ, сожрёт и мельтдаун. Лишь бы только производительность
> в игрушках не снизилась.
Скорость System I/O в многопотоке на i7 и выше в 2.5 раза ниже! Софтаврные патчи! AES-NI тоже уже неэффективен на SSD.
| | |
| |
| 3.28, Геймер (?), 09:06, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Я ж и говорю - костыли костыльные, а не патчи. Хорошо что ещё хоть как-то ползают.
| | |
|
| 2.36, Аноним (-), 12:13, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
В игрушках и не снижается, как ни странно, а вот на серверах очень даже заметно.
| | |
| 2.68, Анонимный Алкоголик (??), 01:00, 07/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> недокументируемая лазейка кому-надо включать мельтдаун
Так у вас недокументированная лазейка есть все дампы свои выкладывать в публичный доступ. Регулярно...
| | |
|
| 1.34, Hellraiser (??), 11:36, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 хе-хе, ну раз гугл утверждает, что патчи не влияют на производительность - значит интел может и дальше штамповать defective-by-design камни; все косяки в железе отныне будут преодолеваться патчами в ядрах ОС
| | |
| |
| 2.38, anomymous (?), 12:28, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> железе отныне будут преодолеваться патчами в ядрах ОС
Я бы, чессгря, нафиг выкинул KPTI из ванильного ядра, и пусть ССЗБ в интелях пилят их сами или отзывают процы. Причём второе сильно вероятнее. По сути эти патчи оказались злом - продолбавший вендор теперь имеет возможность и дальше клепать глюкодром.
| | |
|
| |
| 2.80, Аноним (-), 15:16, 07/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> Пускай считает, что хочет. Есть и другие мнения.
И все мнения по весу равнозначны. Ну или твое сильно весомее. Да, мой дорогой аналитек?
| | |
|
| 1.40, anomymous (?), 13:18, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +17 +/– | |
Ну вот есть у меня очень нагруженный Zabbix сервер под Xen с 8 vCPU (2 CPU x 6 реальных ядер на хосте). С проксями снаружи, блекджеком и дамами.
Number of hosts 7329
Number of items 284444
Number of triggers 143874
В качестве первого выбрал именно его, потому что на нём тонны процессов и сисколов, и эффект от KPTI должен быть заметен сразу.
Что поимел (данные снимал естественно после "прогрева" кэша MySQL и устаканивания опросников Zabbix):
1. "До": Нагрузка всех 8 ядер плавает от 20 до 70%, в основном из-за скриптов сброса данных в систему графиков.
userspace - ~20%, system - ~10%, wa/si - ~1-2%, idle - ~60%. MySQL - 120-220%, с выплесками до 400% (как раз из-за сброса данных для графиков). Ядра в полку не упираются, loadavg около 4-5.
2. "После" (с KPTI): ужОс заметен сразу на графиках в XenServer. Вместо 20-70% имеем от ~50% до "полки" (100%). То есть рост нагрузки на ядра в Zabbix порядка 2 крат (что соответствует 50% падению производительности).
userspace - ~40%, system - ~40%, idle - ~10%, wa/si - ~1-2%. MySQL - ~200-300%, с выплесками до 480% - т.е. KPTI ощутимо шарахнуло по MySQL. Но не только. В топе стало видно опросники и snmpget (по ~1%). Ядра начали упираться (idle=0), loadavg вырос до 11-12.
Вот такие дела. Как только выключаем pti (с ядром RHEL можно "на лету") - сразу же возвращаемся практически к значениям "до".
Итого: заббикс будет летать с pti=off, благо там эксплуатировать уязвимости некому.
| | |
| |
| 2.41, Аноним (-), 13:53, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да в многопотоке просадки KPTI значительные, можно уже заказывать сервера на AMD.
| | |
| |
| 3.44, anomymous (?), 15:11, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Угу :( Там даже не в многопотоке дело, а в куче сисколов. Заббикс - это ж обилие форков, отсылок и получений коротеньких пакетов (icmp, snmp), мелких обращений к БД (соответственно к диску). В общем, практически наихудший для KPTI вариант.
| | |
| |
| 4.46, Аноним (-), 15:33, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Угу :( Там даже не в многопотоке дело, а в куче сисколов.
> Заббикс - это ж обилие форков, отсылок и получений коротеньких пакетов
> (icmp, snmp), мелких обращений к БД (соответственно к диску). В общем,
> практически наихудший для KPTI вариант.
а кто-нибудь сетевое типа Openvpn тестил? там тоже гоняется каждый пакет через kernel-userspace-kernel
интересно, насколько там просело
| | |
|
|
| |
| 3.70, anomymous (?), 09:03, 07/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Да ничего подозрительного. Просто рост нагрузки размазался между юзерспейсом и кёрнелспейсом, что и не удивительно. Там же целых несколько эффектов:
1. Увеличение времени входа-выхода в/из сискола. Это по идее должно попадать в sy, но у меня есть сомнения насчёт трамплина (не анализировал, могу ошибаться) - скорее всего время нахождения в трамплине будет зачтено самому процессу и попадёт в us.
2. Постоянные сбросы TLB однозначно влияют на общее время выполнения кода как в юзерспейсе, так и в ядре. Причём как раз этот эффект слабо предсказуем и зависит как от числа сисколов, так и от активности работы с памятью / разброса адресов при этом. Zabbix в этом плане с его кучей дочерних процессов - опять же худший вариант.
3. Много мелкого обмена с сетью - много прерываний, а поскольку страницы кёрнелспейса теперь как глобальные не объявляются, появляется проблема с вымыванием TLB после выхода из прерываний.
PCID/INVPCID у данного конкретного процессора (Xeon X5670) нет, так что каждый сискол или инт сбрасывает TLB целиком. В общем, при таком числе процессов и объёме постоянного рабочего набора (~20 гиг вместе с MySQL) уже не подозрительно :)
| | |
| |
| 4.75, Аноним (-), 13:20, 07/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>PCID/INVPCID у данного конкретного процессора (Xeon X5670) нет
есть.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU X5670 @ 2.93GHz
..
[root@NodeB mm]# grep pcid /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
PCID
| | |
| |
| 5.77, anomymous (?), 14:05, 07/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да, наличие PCID не заметил. INVPCID нет. В принципе уже PCID должно быть достаточно, пойду гляну, чего там в ведре от EL наворотили тогда.
| | |
| 5.79, anomymous (?), 15:08, 07/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Короче да, погорячился я насчёт пользы от PCID/INVPCID. И RH тут не при чём, в ванильном ядре то же самое.
С PTI процедура переключения контекста очищает оба типа трансляций, то есть всё равно имеем полный флаш, хоть с PCID, хоть без.
Более того, от PCID без INVPCID даже просто для оптимизации сброса TLB толку не много, каждый флаш в пространстве ядра всё равно приводит к полной инвалидации трансляций для всего юзерспейса.
| | |
| |
| 6.102, Аноним (-), 08:10, 09/01/2018 [^] [^^] [^^^] [ответить]
| +/– | |
что-то странное вы говорите товарищ.
.macro ADJUST_KERNEL_CR3 reg:req
/* Clear "KAISER bit", point CR3 at kernel pagetables: */
andq $(~KAISER_SWITCH_MASK), \reg
.endm
.macro ADJUST_KERNEL_CR3_PCID reg:req
bts $X86_CR3_PCID_NOFLUSH_BIT, \reg
/* Clear "KAISER bit", point CR3 at kernel pagetables: */
andq $(~KAISER_SWITCH_MASK_PCID), \reg
.endm
обратить внимание на 2 разницы..
| | |
|
|
|
|
|
| 1.54, iCat (ok), 18:34, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 "Незначительное"... Как-то не утешает...
Блин! Откуда же такая задница вылезла?!
...с 1995 года, оказывается, те, кто знал - читали всё, что хотели...
Но не это главное. Главное, что сейчас миллионы систем "просядут" на 10-30% производительности, или останутся "открытой книгой" для "умельцев"...
Или всё-таки "умелец" должен обладать весьма недюжинными возможностями?
Тогда можно не сильно осторожничать...
Тем более, что основные браузеры уже сильно затруднили использование этой дурки.
Лишь бы не впендюривали насильно!
| | |
| |
| 2.61, ы (?), 22:08, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Достаточно быстро выйдет очередной апдейт wannacry
| | |
|
| 1.56, Maxtor (?), 19:42, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Google - враг мой. Вечно врет, непонятно в чем его выгода, ведь правда лежит на поверхности. Проверил свои сервера с этим патчем и без, потеря производительности почти 40%. Значит, "незначительное"?
| | |
| |
| 2.58, VINRARUS (ok), 20:57, 06/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Google - враг мой. Вечно врет, непонятно в чем его выгода, ведь
> правда лежит на поверхности. Проверил свои сервера с этим патчем и
> без, потеря производительности почти 40%. Значит, "незначительное"?
Прогони игру, по легенде должно полегчать. xD
ПС: печально, значит размер попы не преувеличен.
| | |
| 2.65, Crazy Alex (ok), 00:10, 07/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вряд ли врут, оно от типа назгрузки сильно зависит. В прицнипе вменяемый софт и так старается лишних сисколлов избегать, может, у гугла это и хорошо получается
| | |
|
| 1.63, Аноним (-), 22:58, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Автопросизовители отзывают автомобили если обнаружена критическая проблема.
| | |
| |
| 2.87, RobotsCantPoop (?), 20:44, 07/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
А если в бортовых/развлекательных системах стоят процы от интел, линух и есть доступ в дикие интернеты, то что? Почешутся или уязвимость ничто -- продажи всё!
| | |
|
| 1.64, Аноним (-), 23:04, 06/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Получается сейчас процессоры лучше не покупать? Нужно дождаться выхода принципиально новых моделей?
| | |
| |
| 2.66, Crazy Alex (ok), 00:11, 07/01/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Нужно подождать пару недель пока станет всё ясно с AMD, с шансами у них всё в порядке. А "принципиально новых" придётся год ждать как минимум.
| | |
| |
| 3.95, Oxhorn (?), 19:45, 08/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Да и не факт что через год Intel пофиксит, они там не идиоты - они знали о проблеме ещё на стадии дизайна, только вот ничего не делали чтобы не терять в приросте производительности.
| | |
|
|
| |
| 2.89, Andrey Mitrofanov (?), 10:05, 08/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Вероятно после патча у Google DOS не случился, а всё остальное им
> "незначительно"...
+кстати, "свежее" прочтение субжа:
"никто в гугль не может быть уволен за то, что покупает у интель".
| | |
|
| 1.94, Oxhorn (?), 19:41, 08/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Конечно незначительная потеря для google, они могут себе позволить потратится на доп сотню серверов.
| | |
| 1.99, Аноним2 (?), 00:26, 09/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Мне вот интересно, производители всяких ультрабыстрых SSD поправят количество iops'ов в описании к своим продуктам, или соврать ещё на 20-30% такая уж большая проблема для рынка накопителей.
| | |
| |
| 2.100, Алког (?), 05:16, 09/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Мне вот интересно, производители всяких ультрабыстрых SSD поправят количество iops'ов
> в описании к своим продуктам, или соврать ещё на 20-30% такая
> уж большая проблема для рынка накопителей.
А при чём здесь SSD? (производительность SSD и компъютера с ним - разные вещи).
| | |
|
| 1.109, Аноним (-), 01:00, 10/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Торренты активно работают с диском и сетью, значит ли это что теперь запущенный торрент клиент начнет сильно загружать систему? :)
| | |
|
