В ядро Linux 6.0, релиз которого ожидается в следующий понедельник, принято изменение, решающее проблемы с производительностью систем на процессорах AMD Zen. Источником падения производительности оказался код, добавленный 20 лет назад для обхода аппаратной проблемы в некоторых чипсетах. Аппаратная проблема давно устранена и не проявляется в актуальных чипсетах, но старый обход проблемы был забыт и стал источником снижения производительности на системах на базе современных CPU AMD. Новые системы на CPU Intel старый обходной манёвр не затрагивает, так как в них доступ к ACPI осуществляется при помощи отдельного драйвера intel_idle, а не общего драйвера processor_idle...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57838
это ж сколько киловатт можно будет сэкономить
это ж сколько киловатт газа можно будет сэкономить... (несмешные шутки.EU)
Забытая заглушка для забытого производителя.
Интересно его забыли, #1 в топ500 собран на амд от и до.
он имел ввиду, что в одной из стран о процессорах amd можно забыть. что, собственно, и сделано
М-м-м, какие влажные мрии. В магазинах электроники от них полки ломятся.
Причём тут AMD? Заглушка-то от чипсета, а не от AMD. Чей чипсет?
причём, костыль этот для чипчетов Intel )
Ну кроме того, что этому патчу 20 лет новость особо ничем не примечательна. Норм было норм осталось. Хотя все равно приятно
Не премечательна только из-за того, что настолько процессоры по скорости быстрее, что эту разницу заметить визуально не возможно без тестов 32191 MB/s до 33805 MB/s. А еслибы было так: 2191 MB/s 3805 MB/s уже существеннее и грустно. А так: 191 MB/s до 805 MB/s ай карамба!
что настолько нынешнее процессоры по скорости быстрее чем процессоры произведённые 20 лет назад.
Надо просто оригинал всегда читать, авторы новостей как обычно не дописывают. По ссылке к патчу минимальное значение скорости выросло с 2215.06 МБ\с до 33072.10 МБ\с, например.
С таким разбросом между максимальной и минимальной скоростью круто было бы гистограмму до/после увидеть. Разница на порядок.
да не интересно совершенно. код не влиял напрямую на производительность, а вносил задержку, соответственно чем короче измеряемое действие, тем большее влияние на измеренную скорость будет вносить эта задержка.
С 32191 до 33805 - это только медианное значение. В редких случаях падение производительности было до 2215, а после патча такие падения исчезли.
Не совсем по теме, но новость того заслуживает. А не хочет ли MS нахлобучить всю open source парадигму? youtube. com/watch?v=tJdHAJnKqFs
Таких забытых заплаток (если копнуть)наберется наверное немало (и размер ядра тогда уменьшится на треть?).
наверное, очень мало наберётся. или вообще не наберётся
Так и есть! Два миллиона глаз, говорили они...
ну так видишь, таки сработало
А в оффтопике до сих пор тормозят неугодное железо.
> А в оффтопике до сих пор тормозят неугодное железо.А там вообще профайлинг по функциям ядра - замотаешься делать. Поэтому даже майкрософт этот рокетсайнс не очень то и практикует, с известным результатом - "обгоняет Linux", ога.
Сработало... через двадцать лет.
20 лет назад добавили заглушку
Ща выяснили, что Zen'ам она не нужна
Zen появился в 2016м
> Так и есть! Два миллиона глаз, говорили они...Всячески поддерживаю этот комментарий и шлю лучи поноса тем, кто его заминусовал.
В Debian про это и не вспомнят ещё двадцать лет, скорее всего.
У них backports есть, в том числе и для ядер. Впрочем вон то могут наверное и в любое иное ядро портануть: тривиальный патч из 2 строк.
Вдруг стабильность нарушится и ядерный реактор сломается? Не, низзя.
не смешно. в обсуждении уже предположили, что патч в таком виде может затронуть старые не-intel системы
Ты вот сейчас смеешься. А в своё время на одной АЭС нашли БЭСМ-6 хотя считалось что ни одной такой машины больше не осталось на тот момент. А потом её в Политехнический музей увезли.
> Ты вот сейчас смеешься. А в своё время на одной АЭС нашли
> БЭСМ-6 хотя считалось что ни одной такой машины больше не осталось
> на тот момент. А потом её в Политехнический музей увезли.А это не ЧАЭС была случайно? С реактором то что?!
Таки читайте уже наконец Дятлова, как и меня тут в своё время носом ткнули в ответ на глупость.
В Linux хотя бы находят
А в BSD полтора землекопа и не найдут
А в BSD амуди ничего не добавлял
> А в BSD амуди ничего не добавлялБыло бы очень странно если бы амд патч добавлял для древних интелов и их проблем хоть куда. А если в бзде не было такого кода - там что, всех устраивало что система виснет на тех интелах? Или как у них было сделано чтобы и на елку влезть и зад не ободрать?
kernel.org:
Latest Release: 5.19.11Debian:
linux-image-5.19.0-2-amd64 (5.19.11-1)
Linux 5.19 for 64-bit PCs (signed)
https://packages.debian.org/sid/linux-image-5.19.0-2-amd64Опакечено: Sat, 24 Sep 2022 13:05:59 +0200
Та кого sid интересует
Тех, кому на убунту идти стыдно, а пользоваться софтом 2010 года выпуска противно.
Эх, дети. Хороший был софт в 2010 году. Ставил несколько лет назад дистрибутив тех лет на машинку тех лет -- чуть не прослезился.Корпы вроде IBM с тех пор линукс и фрисофт не просто жрут, а уничтожают -- пока без особых "подрывов газопроводов", но как только посчитают, что так выгодней -- нагадят ещё по полной.
> Эх, дети. Хороший был софт в 2010 году. Ставил несколько
> лет назад дистрибутив тех лет на машинку тех лет -- чуть
> не прослезился.Что же помешало сохранить? Как ныне любят говорить «тю, можно запросто форкнуть Qt5». Мне, например, помимо своих ошибок, помешал пожар Москвы в 2010-м. И ещё деятельность одной из сект, кои готовили к грядущим событиям. Кстати, герой 11-го Прилепин таки оказался человеком Реймана и одним из первых импортозаместился на «Российскую ОС».
> Корпы вроде IBM с тех пор линукс и фрисофт не просто жрут,
> а уничтожают -- пока без особых "подрывов газопроводов", но как только
> посчитают, что так выгодней -- нагадят ещё по полной.Повеяло свеженькими розами с их вечным «апстрим всё сломал». :) Это называется «действовать в интересах своей страны» и вполне -- от них -- ожидаемо.
Интересно, а из других версий ядра будут эту заглушку удалять, или останется как не критичная?
По-моему в описании новости гон.
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ return;
Судя по коду и коменту рядом ускориться должно "все что не древний интел".
Заплатка была для штеуда, а влияла и на AMDА что она тормозила штеуд всем наплевать)
> А что она тормозила штеуд всем наплевать)Какой-то древний вариант оного, там более продвинутая проверка для intel'ов дальше. А что делать если иначе зависон? Вам зависоны больше нравятся?
This also assumes that the motivating chipset issue was Intel-only.
хм.. тоесть для амд воркэраунд был ненужен никогда..
всвязи с этим интересно сколько производительности теряли старые процессоры амд из-за этого воркэраунда который им был не нужен..
> всвязи с этим интересно сколько производительности теряли старые процессоры амд из-за этого
> воркэраунда который им был не нужен..Сильно зависит от задачи. Но мне тоже было странно что на незагруженной системе вон то занимает многовато времени.
И интересно, что человек из АМД, проделавший всю работу [1], и пославший исправление, в итоге, не является автором патча [2]. Человек из Интел оформил его исправление по-другому - и вуаля - автор![1] https://lore.kernel.org/lkml/20220921063638.2489-1-kprateek..../
[2] https://lore.kernel.org/lkml/67154681-0e0a-69d7-d4ee-21067c9.../
и что? вы думаете, что эта разработчики трудятся исключительно чтобы потешить тщеславие?как вижу ситуацию я:
1. сотрудник amd обнаружил в коде задержку, которая не требуется современным системам amd и опубликовал соответствующий патч, в которой отключил эту задержку на zen;
2. сотрудник intel произвёл мини-расследование и обнаружил, что эта задержка была добавлена для актуальных 20 лет назад чипсетов intel и предложил свою версию патча, которая отключает эту задержку на всех не-штеуд системах (предполагая, что проблема затронула только intel);
3. другие разработчики предположили, что эта задежка, возможно, была необходима и для других старых систем:
https://lore.kernel.org/lkml/Yyy6l94G0O2B7Yh1@rhlx01.hs.../идёт вполне нормальная коллективная работа; и, вполне вероятно, скоро в ядро вольют третью версию патча.
> и предложил свою версию патчаТ.е. на код-ревью выкидываешь то, что кто-то написал, - и подаёшь своё "новое". И несмотря на почти один и тот же эффект не ставишь оригинального автора хотя бы в со-авторы. Хм.
Но первое исправление совсем неполное, там только для zen отключение.
Завтра amd выпустит новую архитектуру izen и её также будет тормозить.
Не говоря уже об всех предыдущих процессорах amd и всех остальных производителей.
> И интересно, что человек из АМД, проделавший всю работу [1], и пославший
> исправление, в итоге, не является автором патча [2]. Человек из Интел
> оформил его исправление по-другому - и вуаля - автор!
> [1] https://lore.kernel.org/lkml/20220921063638.2489-1-kprateek..../
> [2] https://lore.kernel.org/lkml/67154681-0e0a-69d7-d4ee-21067c9.../И интересно, что в оригинале оно выглядит не совсем так, как интерпретировано выше:
Reported-by: K Prateek Nayak <***@amd.com>
Suggested-by: Rafael J. Wysocki <***@intel.com>
Signed-off-by: Dave Hansen <***@linux.intel.com>
Reviewed-by: Mario Limonciello <***@amd.com>
Tested-by: K Prateek Nayak <***@amd.com>
Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.n.../
Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hans...
> Reported-by:Если кто-то обнаруживает проблему и описывает, как на неё наткнуться, т.е. создаёт хороший баг-репорт, то его записывают в эту графу.
АМДшник же не просто нашёл условия, при которых тормозит, он нашёл код, который приводит к тормозам. И исправил. Да, оказалось, можно чуть лучше оформить исправление. В любом случае не надо было его деградировать до "просто" сообщившего об ошибке, а хотя бы добавить в "Co-Authored-By:".
Да не исправил он, а решил для частного случая: boot_cpu_has(X86_FEATURE_ZEN).
Если бы это приняли, то для других процессоров вероятно вообще бы никогда не исправили.Интелы по сути признали, что только их изделиям свойственна проблема: boot_cpu_data.x86_vendor != X86_VENDOR_INTEL
АМД произвели ревью, то есть проконтролировали, что всё сделано правильно. Обнаружившего и так два раза упомянули, плюс ссылка на первую версию.
Вот так операционные системы начинают тормозить в процессе своей эволюции. Что делать? Ну конечно, купить новое железо. Очевидно же.
Если бы железоделатели чуть более консервативно выпускали железо, то и проблем было б меньше.
775 сокет с 2008 года до сих пор по сей день сижу и не вижу смысла менять шило на мыло.
Поменяю и будут явные проблемы с Linux потому что что? правильно! - динамичное железо. Хотя в целом эта ось оседлала большинство железа, включая ARM. Так что не фиг гнать
> динамичное железоЧто за определение такое локалхостовое?
>по сей день сижуНичего, вот выйдешь на свободу и купишь себе нормальный комп.
Мда, запущенное ретроградство
775 сокет это мимо сабжа это же штеуд, а не AMD.
Как что, написать с нуля без поддержки легаси и естественно на rust.
Так сравни то, что умеют десктопные операционки сейчас и тридцать лет назад.
Мой самый любимый пример - ввод текста с клавиатуры.
Раньше, по крайней мере в DOS:
1. получил запрос на чтение одного символа через int 21h;
1. принял прерывание 09h;
2. проверил скан-коды и преобразовал их в символ;
3. вернулся прерывания в программу;
4. программа вызывает прерывание или напрямую кладёт символ в видеопамять (при этом единственный шрифт уже хранится в памяти).
То сейчас той же винде нужно:
1. получить сигналы от всех устройств ввода;
2. прогнать через все хуки и глобальные сочетания клавиш;
3. узнать, какому приложению нужно отправить сообщение о нажатии клавиши;
4. преобразовать скан-коды в символ в нужной раскладке и языке;
5. приложение наконец-то принимает его и выводит на экран (предварительно проверив уже свои сочетания клавиш);
6. для вывода нужно определить шрифт, получить параметры символов, определить символы поблизости (для кернинга), определить специальные лигатуры и т. п.;
7. наконец, надо отрендерить этот несчастный символ, со всеми субпиксельными сглаживаниями, и именно в нужном месте;
8. картинку с экрана нужно отправить видеокарте, чтобы она уже окончательно вывела её на монитор.
Поэтому, кстати, среднее время между нажатием на клавишу и отображением символа за все эти годы не уменьшилось. Просто сам процесс стал гораздо более сложным.
Так и в целом. Можно вполне работать в тех же Kolibri OS, которые более мелкие и шустрые. Но в них нет всех тех функций, к которым мы уже привыкли в Windows/Linux/MacOS, и которые делают эти системы такими большими и неповоротливыми.
Ну да. И в usb допустим как таковом никаких прерываний и нет. По поводу чего в DOS он почти и не работает, кроме совсем минимального эрзаца который аж через, кажется, SMM-бэкдор надувает программы что это, типа, тоже клавиатура и мышь. В сильно урезаном "boot mode", ога. Остальное вообще в пролете.А что до рендера - особо прошареные, типа игроделов, доперли рендерить векторные фонты со всеми наворотами 1 раз а потом готовый битмап доставать. А что до передать картинку - с тех пор DMA движками все сильно подперли, да и видеокарта так то нехилый массив ALUшек, в теории даже на ней можно вектор рендерить, на практике оформить столь продвинутые шейдеры, конечно, весьма экзотично.
И не одна. Был баг с нуво и оптимус, поправили добавив dirty hack и забыли.
А как с камнями AMD постарше?Piledriver, там, Bulldozer, K10.5?
Оно походу тормозило все что не древний интел.
if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) return;
Вспоминаем анекдоты про тормоза из за специально добавленного где-то Wait.
О, а можно порт на старые ядра? 2.6.9, 2.6.18, 2.6.27, 2.6.32, 2.6.37, 3.2, 3.10, 3.11, 3.16? Просто я же люблю старые линуксы, постоянно их запускаю. Го порты на старые ядра, пожалуйста...Вспомнился один случай. У меня есть компик на базе чипсета от VIA (даже не один). Помните чипсет VIA KX133, когда надо было ещё ставить драйвер VIA 4-in-1 4.43?
Так вот, я решил вставить видеокарточку, предназначенную для AGP 8x. И вдруг - глюки, артефакты, проблемы. Оказалось, что шина AGP почему-то работает на скорости 2x, тогда как видеокарта поддерживает только 4x и 8x. Отсюда и глюки из-за того, что куда надо 3,3 V, подаётся 5,0 V. Почему так произошло?
Оказалось, что когда-то давно в старых чипсетах VIA была аппаратная проблема. Из-за этого, в драйвере NVIDIA ForceWare 30.xx и более новых, AGP на этих чипсетах принудительно переводится в режим 2x. А в более старых драйверах 28.xx (2002 год) всё работало в режиме 4x.
Есть параметр, чтобы обойти эту проблему (под Windows и Linux). "NVreg.EnableVia4x=1". С ним AGP 8x карты работают, как надо.
Под виндой в какой-то момент запретили cool-bits (чтобы получить сертификат WHQL), поэтому этот параметр работает только под Win98 и Win2000. Под XP надо ставить дрова VIA 4-in-1, и в какой-то момент будет задан вопрос: "Вам стандартная установка, или Turbo-установка?", и я всегда выбирал стандартную - ведь я же не разгонщик. А оказывается, что если выбрать Turbo-установку, то будет работать AGP 4x с новыми дровами NVIDIA.
Оказалось, что баг проявляется на совсем уж старых материнских платах, предназначенных для Pentium II и AMD K6. А на моих третьепнях и атлонах не проявляется. Поэтому можно смело переводить видеокарту в режим AGP 4x и не париться. Позже я даже увидел в обзоре по-моему от Old Robot - тест старой материнки под Super Socket 7 (они ведь уже имели AGP 4x на борту? может на какой-то более поздней материнке), и этот самый баг, ради которого блкировали AGP 4x, был наглядно воспроизведён
Это твой шанс стать кернел-разработчиком и пропатчить 2.6.9, 2.6.18, 2.6.27, 2.6.32, 2.6.37, 3.2, 3.10, 3.11, 3.16. Я уверен, пользователи 2.6.9, 2.6.18, 2.6.27, 2.6.32, 2.6.37, 3.2, 3.10, 3.11, 3.16 на новом АМДшном железе это высоко оценят.
Там патч 1 строчка кода
> Там патч 1 строчка кодаТак я об этом и говорю.
Ну тогда уж не разработчиком, а мейнтейнером. Да и пересобрать ядро для линуксоида с 15-летним стажем не так уж и трудно
Процесс адаптации патча может оказаться куда интереснее, чем ты ожидал, так что придётся тебе вкатиться и в разработку, и в тестирование тоже.
> на новом АМДшном железеДа в смысле "на новом"? Выглядит так, как будто баг в чипсетах поправили лет где-то 20 назад
>> на новом АМДшном железе
> Да в смысле "на новом"? Выглядит так, как будто баг в чипсетах
> поправили лет где-то 20 назадОчень новое, а вот чтобы это выяснить, понадобится обзавестись коллекцией такого железа и подготовить методику тестирования и сравнения, чтобы потом по ней следовать. Вперёд, занятие на ближайшие 20 лет есть.
Выше пишут, что для AMD воркэраунд и не был нужен никогда
Я тоже люблю и коллекционирую старое железо и ОС,
но раритеты стараюсь сохранять в историческом виде,
то есть но старом железе, стоит старая ОС и ПО адекватное возможностям железа.Если в старый комп напихать ОЗУ, сколько при его активной жизни было невозможно, втиснуть современные SSD и видеокарту, то это будет не исторический экземпляр, а просто плохой компьютер.
Конечно, бывает ради интереса, и балуюсь с выжиманием большего из старья.
Например на Win98 можно запустить ПО от Win2000. Польза от этого какая то сегодня есть? Нет. Но когда был актуален W98, и это могло быть полезным, оно не было возможно. Так что это почти жульничество.
Если старое железо работало раньше, то так пусть и сохраняется, как есть.Можно разве что из правильного(не любого) Core2Duo сделать машину для вполне полезных нужд. Но что то более старое мучить... Так себе идея.
PS:
>> 2.6.9, 2.6.18, 2.6.27, 2.6.32, 2.6.37, 3.2..По номерам версий зачёт! Чувствуется, что с драйверами работали.
Да нет, просто это LTS-ядра, которые долго получали обновления. Кроме 2.6.37, просто это ядро из openSUSE 11.4, которой я пользуюсь чаще всего
Похоже, почти полность нивелировали снижение производительности из-за патча против retbleed, вот старые новости:
https://www.opennet.dev/opennews/art.shtml?num=57496
https://www.opennet.dev/opennews/art.shtml?num=57769
https://www.phoronix.com/news/Retbleed-Call-Depth-Tracking&n...
AMD Zen3? Выглядит так, как будто баг в чипсетах поправили где-то в 2005 году. А фикс применили только для последних процессоров
Блин, 5 раз прочитал: "В ядре Linux найдена забытая зарплата, влияющая на производительность CPU AMD" - и пытаюсь понять причем тут чья-то зарплата. Вы бы хоть использовали аутентичный "патч" или "заплатка".
У тебя проблемы с зарплатой. Тебе бы уже давно пора было найти уже работу с нормальной зарплатой. Чтобы она тебе везде не мерещилась.
Вангую, автору пришлось выкручиваться с синонимами из-за того, что на опеннете слово "костыль" мат-фильтр не пропускает.
А в оффтопике производитель конкурирующей фирмы может даже заплатить чтобы в ядре оффтопика оставили такие заплатики для другого производителя. Да и сабжевую, наверняка по настойчивой просьбе штеуда забыли.
Получается, что процессоры AMD можно ускорить нахаляву, удалив одну строчку кода из исходников ядра?
А чему вы удивляляетесь? Говорят раньше у Штеуда был компилятор, который так лихо оптимизировал код под выполнение на их процах, что результат начинал тормозить на AMD. Особо учидчивые рзработчики (вроде японцев) порой компилировали отдельно сборки под Интолл и обычным компилятором под AMD\все остальное.
> А чему вы удивляляетесь? Говорят раньше у Штеуда был компилятор, который так лихо оптимизировал код под выполнение на их процах, что результат начинал тормозить на AMD.Да, и потом Дмитрий Беседин нашел почему и выпустил патчер, который возвращал нормальную производительность amd камням после интеловского компилятора. ЕМНИП, общий смысл тот же был - SIMD использовалось если это intel камень, и игнорировалось, если cpuid от amd.
А это как-то исправляет зависания при длительной компиляции? Нет? 🧯
Значит страдания ВО СЛАВУ АМД продолжаются? ❤️🔥
Что за зависания?
Мне тоже интересно, пожалуйста. Компиляю на рязани регулярно, сталкивался только пару лет назад с известным сегфолтом gcc (уже прошло, похоже).
Подорожник прикладывал?
> Мне тоже интересно, пожалуйста. Компиляю на рязани регулярно, сталкивался только пару лет
> назад с известным сегфолтом gcc (уже прошло, похоже).Попробуй в дефолтсити компилять, вдруг у тебя место радиоактивное?!
Это не те, которые АМД решила заменой бракованных чипов? Как ты это в софте решишь?
> А это как-то исправляет зависания при длительной компиляции? Нет?У меня амд и ничего не виснет даже если месяц аптайма и билдить все что билдится. Нефиг паленую оперативку покупать.
Всегда появляются АМД-боты, у которых абсолютно ЛЮБОЙ ПРОДУКТ ОТ AMD ПРОСТО ИДЕАЛЬНО ПРОСТО РАБОТАЕТТак же они пишут, что 240Ватт - это печка, а не процессор, но если АМД выпускает соккет, который не плавится мгновенно, как китайская игрушка выделяя при этом токсичные пары, то уже 250Ватт становятся "нормой"
Со дня на день выйдет процессор с TDP 253Ватта и те же самые боты будут опять писать, что это очень много, хотя они же вчера писали, что 250Ватт это "окей"
> компиляцииНа дворе 2к22 год, ты чё, в сосну ударился, какая компиляция
Не просто заплата, а целое заплатище! )
А у нас скоро вырастут сосули...
Или я снова проснулся в другой реальности где есть слово "заплата"? (:
В гугле забанили чтоли?
Переводя с низкоуровнего на прикладной - "sleep-чики удалили". Грандиозно что есть такой низкоуровневый профайлер!
Браузер наконец перестанет фризить и статтерить при скроллинге?
Когда удалят большую часть заплаток, то прекратится поддержка почти всего оборудования
6.0-rc7
гдее?
нет никакого 6 ещё в проде
Сама идея линукса - засовывать все драйвера в ядро - глубоко порочна. В винде сделано разумнее, нужные драйвера устанавливаются отдельно. И не получается мусорка со всевозможными драйверами давно мертвых устройств.
Если бы проблемный драйвер был для «мёртвого устройства», он бы не использовался и проблемы бы не было.