64 битное ядро linux

Как узнать, является ли мой Linux 32-битным или 64-битным?

Мне нужно выяснить, работает ли мой сервер Linux в 32-битной или 64-битной системе.

Как я узнаю, является ли мой Linux 32-битным или 64-битным?

Чтобы проверить, работает ли на вашем сервере Linux 32-битная или 64-битная система, попробуйте следующую команду

• Получить ВСЕ данные о ЦП в Linux, Выполнить: lscpu или cat /proc/cpuinfo
• У меня работает ядро Linux 32-битное или 64-битное? Выполнить: getconf LONG_BIT
• Мой процессор в 32-битном или 64-битном режиме? Запустите: grep -o -w ‘lm’ /proc/cpuinfo | grep -у

Linux знает информацию об архитектуре процессора

Введите следующую команду lscpu:

Из приведенного выше вывода ясно, что у меня есть:

• Процессор: AMD A10-6800K APU with Radeon(tm) HD Graphics
• Архитектура: x86_64
• Процессор может работать: 32-битная или 64-битная операционная система

Узнайте,процессор работает d 32-битный или 64-битный в системе Linux

Просто запустите следующую команду grep

Флаг lm означает процессор в длинном режиме, то есть 64-битный процессор.

Для получения дополнительной информации введите следующую команду cat, чтобы получить полную информацию о вашем процессоре:

Как я узнаю, является ли мой Linux 32-битным или 64-битным?

Теперь вы знаете, что у вас есть процессор AMD, который может работать как в 32-битной, так и в 64-битной операционных системах.

Но как узнать, является ли мое текущее ядро и дистрибутив Linux 64-битным или 32-битным?

Не бойтесь, выполните следующую команду:

Команда getconf проверяет, является ли ядро Linux 32-битным или 64-битным.

64 означает, что у меня 64-битное ядро Linux и дистрибутив Linux.

Другая команда Linux, чтобы проверить, есть ли у меня 32-битная или 64-битная ОС

Для 64-битных вы получите x86_64 и i386 для 32-битных процессоров Intel.

Примечание о методе GUI

Откройте дистрибутив Linux, окно «Настройки» и выберите «Сведения о системе»:

Используйте команду lshw

Выполните следующую команду lshw, чтобы вывести всю информацию о процессоре:

Заключение

Вы узнали, что большинство серверов на базе Intel и компьютер могут работать как с 32-битной, так и с 64-битной операционной системой.

Далее вы узнали различные параметры командной строки, чтобы определить, используете ли вы 32-разрядную или 64-разрядную версию ядра Linux и операционных систем.

Источник

32-битный, 64-битный режим работы процессора в Linux

Я не совсем понимаю. Запуск Fedora Linux lscpu дает:

Но когда я пытаюсь установить 64-битную программу (Chrome), я получаю сообщение об ошибке:

Пакет /. x86_64.rpm имеет несовместимую архитектуру x86_64. Допустимые архитектуры: [‘i686’, ‘i586’, ‘i486’, i386 ‘]

Меня меньше интересует возможность установки Chrome и больше интересует, почему lscpu говорится, что мой процессор может работать в 64-битном режиме; очевидно, это не значит, что я могу запускать 64-битные программы. Кто-нибудь может уточнить?

lscpu говорит вам, что ваша архитектура i686 (32-разрядный процессор Intel), и что ваш процессор поддерживает как 32-разрядный, так и 64-разрядный режимы работы. Вы не сможете установить x64-приложения, поскольку они созданы специально для x64-архитектур.

Ваш конкретный процессор может работать со встроенными пакетами i386 или i686. Есть несколько способов проверить вашу архитектуру и настройки ОС.

lscpu

Как вы уже знаете, вы можете использовать команду lscpu. Он хорошо дает вам приблизительное представление о том, на что способен ваш процессор.

/ Proc / CPUInfo

На самом деле это данные, предоставляемые ядром, которые большинство инструментов, например, lscpu используют для отображения. Я нахожу этот вывод немного приятным в том, что он показывает некоторую информацию о номере модели вашего конкретного процессора. Также он покажет вам раздел для каждого ядра, которое может иметь ваш процессор.

Вот вывод для одного ядра:

Вот как выглядят первые 3 строки каждого раздела для ядра:

Выходные данные /proc/cpuinfo также могут сказать вам тип архитектуры, которую ваш процессор предоставляет через различные флаги, которые он показывает. Обратите внимание на эти строки из приведенной выше команды:

Флаги, заканчивающиеся на, _lm говорят вам, что ваш процессор поддерживает «длинный режим». Длинный режим — это другое название для 64-битного.

uname

Эта команда может использоваться, чтобы определить, какую платформу поддерживает ваше ядро. Например:

64-битное ядро

32-битное ядро

Этот выход может быть уточнен немного дальше с помощью переключателей, [-m|—machine] , [-p|—processor] , и [-i|—hardware-platform] .

Вот этот вывод для тех же систем выше.

64-битный

32-битный

ПРИМЕЧАНИЕ. Существует также краткая версия, uname -m которую вы можете запустить как отдельную команду arch . Возвращает точно так же, как uname -m . Вы можете прочитать больше о arch команде в документации coreutils .

arch выводит имя оборудования машины и эквивалентно ‘uname -m’.

HWiNFO

Наверное, лучший инструмент для анализа вашего оборудования должен быть hwinfo . Этот пакет может показать вам практически все, что вы хотите / должны знать о любом из ваших аппаратных средств, прямо с терминала. Это спасло меня в десятки раз, когда мне понадобилась бы некоторая информация о чипе на материнской плате системы или мне нужно было узнать ревизию платы в слоте PCI.

Вы можете запросить его в отношении различных подсистем компьютера. В нашем случае мы будем смотреть на cpu подсистему.

Опять же, аналогично /proc/cpuinfo этой команде показывает состав каждого отдельного ядра в многоядерной системе. Вот первая строка из каждого раздела ядра, просто чтобы дать вам представление.

getconf

Это, вероятно, самый очевидный способ сказать, какую архитектуру ваш процессор представляет ОС. Используя getconf ваш запрос к системной переменной LONG_BIT. Это не переменная окружения.

Еще один инструмент, похожий по возможностям на hwinfo . Вы можете запросить практически все, что вы хотите знать о базовом оборудовании. Например:

Операционные режимы процессора?

Некоторые из команд сообщают, что 32-разрядный процессор поддерживает 32-разрядный и 64-разрядный режимы. Это может немного сбивать с толку и вводить в заблуждение, но если вы понимаете историю процессоров, в частности Intel, вы будете знать, что у них есть история игр с их продуктами, где процессор может иметь набор инструкций, который поддерживает 16-битные но может адресовать больше оперативной памяти, чем 2 ^ 16.

То же самое происходит с этими процессорами. Большинство людей знают, что 32-разрядный процессор может адресовать только 2 ^ 32 = 4 ГБ оперативной памяти. Но есть версии процессоров, которые могут адресовать больше. Эти процессоры часто используют ядро ​​Linux с суффиксом PAE — расширение физического адреса . Использование ядра с поддержкой PAE вместе с этим оборудованием позволит вам адресовать до 64 ГБ в 32-битной системе.

Тогда вы можете подумать, зачем мне 64-битная архитектура? Проблема с этими процессорами заключается в том, что пространство одного процесса ограничено 2 ^ 32, поэтому, если у вас есть большая имитационная или вычислительная программа, которой требуется больше 2 ^ 32 адресуемого пространства в ОЗУ, то это не помогло бы вам с этим.

Взгляните на страницу википедии по микроархитектуре P6 (i686) для получения дополнительной информации.

TL; DR — Так какого черта архитектура моего процессора?

В общем, это может сбить с толку, потому что ряд команд и методологий выше используют термин «архитектура» свободно. Если вас интересует, является ли базовая ОС 32-битной или 64-битной, используйте эти команды:

Если, с другой стороны, вы хотите знать архитектуру процессора, используйте эти команды:

В частности, вы хотите искать поля, в которых говорится что-то вроде «ширина: 64» или «ширина: 32», если вы используете инструмент, подобный lshw , или искать флаги:

• lm : Длинный режим (x86-64: amd64, также известный как Intel 64, то есть 64-разрядный)
• lahf_lm : LAHF / SAHF в длинном режиме

Присутствие этих двух флагов говорит о том, что процессор 64-битный. Их отсутствие говорит вам, что он 32-битный.

Посмотрите эти URL для получения дополнительной информации о флагах процессора.

Источник

Debian: простое превращение i386 в amd64

Это краткая статья о том, как без переустановки организовать 64-битную архитектуру на вашем 32-битном Debian/Deabian-based дистрибутиве (который вы могли по-невнимательности загрузить вместо 64bit).

* Ваше железо должно изначально поддерживать amd64, магию творить никто не собирается.
* Это может повредить систему, так что действуйте очень осторожно.
* Всё проверялось на Debian10-buster-i386.
* Не делайте этого, если хоть что-то здесь не понимаете.

Dpkg, apt и sources.list

Сразу к делу, если вы сумaсшедший всё взвесили, начинаем подготовку пакетов (в принципе здесь порядок не имеет значения, но по пунктам удобнее)

1. Выбираем amd64 в /etc/apt/sources.list, вставляя ‘ [arch=amd64] ‘ между deb\deb-src и URL

Это нужно для того, чтобы в будущем загружались только 64-х битные пакеты.

2.Добавляем amd64 в dpkg, чтобы он не ругался:

3.Обновляем список пакетов:

Разумеется всё это не имеет смысла без 64-х битного ядра, поэтому устанавливаем его:

Место $VERSION подставить нужную версию ядра.

После установки ядра grub перенастроится автоматически.

Завершение

После перезагрузки наша система уже сможет работать с amd64, но с пакетами могут возникнуть некоторые проблемы. У меня для их решения было достаточно выполнить данные команды:

Хотя сильно на этот счёт беспокоиться тоже не стоит — все нужные пакеты со временем сами установятся как зависимости, а ненужные удаляются так:

Источник

Насколько маленьким может быть ядро linux?

Некоторое время назад я научился конвертировать виртуальные машины в oracle cloud из ubuntu 20.04 в gentoo. Машины предоставляемые в рамках always free tier весьма маломощны. Это в частности приводит к тому, что перекомпиляция ядра превращается в достаточно длительный процесс. У исходного ядра ubuntu 20.04 в конфиге было 7904 параметра. После того, как я сделал:

число параметров уменьшилось до 1285. Мне стало интересно попробовать выбросить из ядра все лишнее и посмотреть, что получится.

Я буду компилировать ванильное ядро 5.4.0, потому что именно эта версия используется на моей установке gentoo. Для ускорения процесса я компилирую ядро на своей рабочей машине (i7, 8 cores, 64Gb RAM, tmpfs). Готовое ядро я копирую на машину в oracle cloud. Начинать процесс надо с команды:

В результате у вас появится файл .config для минимального ядра текущей архитектуры. В моем случае в этом файле оказалось 284 непустых строк, не являющихся комментариями.

Давайте скомпилируем его и посмотрим на размер ядра:

Это ядро абсолютно бесполезно. Оно не только не может загрузиться но даже не имеет возможности сообщить о возникших проблемах. Давайте это исправим. Для активации параметров я буду использовать команду:

Итак, наше ядро будет 64-битным, мы активируем вывод диагностики ядра, включаем поддержку терминала, конфигурируем последовательный порт и консоль на нем:

Машина в oracle cloud загрузиться с этим ядром не сможет, вывода на консоль не будет. Как оказалось, надо добавить поддержку EFI и ACPI, являющуюся ее зависимостью. Скрипт ./scripts/config не реализует логику добавления обратных зависимостей т.е. если добавить только CONFIG_EFI, то make выкинет этот параметр из конфига. Также стоит отметить, что включение опций часто включает нижележащие опции. Так в случае с включением CONFIG_ACPI автоматически включается, к примеру, поддержка кнопки включения/выключения.

Это ядро по прежнему не может завершить процесс загрузки, но по крайней мере способно сообщить об этом:

Давайте добавим необходимые параметры:

И загружаемся. На этот раз ядро успешно находит корневой диск, но в консоли мы видим ошибки:

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

На этот раз нам удается залогиниться:

Ура! Ssh тоже работает. Тем не менее в консоли опять есть ошибки:

А в dmesg находим еще:

Добавляем поддержку часов реального времени, файловой системы vfat и inotify:

Хммм, vfat диск по прежнему не может подмонтироваться:

А вот и ответ почему в dmesg заодно с еще одной ошибкой:

Загружаемся, в консоли ошибок нет, но появилась новая ошибка в dmesg:

Перезагружаемся и на этот раз не видим новых ошибок!

На моей рабочей машине (i7, 8 cores, 64gb RAM, tmpfs) финальная конфигурация собирается за 1m 16s. В oracle cloud с двумя ядрами и на обычном диске этот же процесс занимает 19m 51s.

Получившееся ядро не является абсолютно минимальным. Так, например, включение поддержки сети добавляет кучу разных сетевых адаптеров. Я не стал заниматься перфекционизмом и вычищать абсолютно все, что не нужно. Кроме того хочу предупредить, что хотя загрузка и быстрое тестирование не выявило проблем с отсутствием дополнительных важных компонент ядра скорее всего таковые существуют. Так что если вдруг вы решите переиспользовать мой конфиг пожалуйста тщательно протестируйте ядро для вашего конкретного случая и при необходимости добавьте нужные параметры ядра.

Источник

Оптимизация Linux для desktop и игр

В этой статье я хочу поделиться почти 10-летним опытом использования Linux на домашнем компьютере. За это время я провел много экспериментов над ядром, испробовал различные конфигурации для разных применений и теперь хочу все это систематизировать в длинный пост с рекомендациями как выжать из linux максимум и добиться отличной производительности, без необходимости покупать мощное железо.

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

Хоть я и пообещал, что после прочтения этой статьи, можно будет играть в Metro 2033 на калькуляторе (шутка, такого не будет), все же она начнется с рекомендации купить кое-что из железа, если у вас этого еще нет.

1. Купите SSD, если у вас его еще нет

Почему-то многие люди скептически относятся к SSD, хотя это первый и важнейший компонент компьютера, который собирается быстро работать.

Серьезно, все что описано дальше в статье даст вам какой-то прирост в производительности и времени отклика, но любой, даже самый дешевый SSD, сократит время запуска большинства программ до 0, что, визуально, будет очень заметно. Почти в любом компьютере (и сервере) главный тормоз это всегда дисковая подсистема и никакой HDD никогда не даст вам нужной скорости поиска (которая у SSD стремится к 0 мс). За все время общения с компьютерами и их апгрейда, только переход на SSD дал значительный прирост в скорости работы и отклике. Помните как медленно работают дискеты, какое у них огромное время поиска? Примерно вот так воспринимается жесткий диск после SSD.

Так что если у вас еще нет SSD, то продолжать дальше смысла нет, ваш компьютер (хоть даже оснащенный 12-ядерным Xeon’ом) все равно будет работать медленно, так что вперед за покупками.

Касательно надежности: есть миф что SSD умирают спустя год. Его рождению мы обязаны первым SSD на бажных чипах SandForce. Естественно, любой новый SSD из магазина как минимум надежнее и долговечнее современных жестких дисков, так что не стоит беспокоиться по этому поводу вообще. Свой SSD я купил 2 года назад б/у, на то время он был в использовании год. Сейчас у него 11 681 часов наработки и использование ресурса 10%, так что при том же режиме использования, мне его хватит еще на 27 лет. Думаю, к этому времени технологии хранения данных уже несколько раз изменятся. Так что повторюсь, проблемы с надежностью более чем надуманы.

Более подробно о мифах SSD расписал товарищ Вадим Стеркин в своём блоге. Правда, блог у него о Windows, но сути это не меняет. Настоятельно советую почитать, очень интересно.

В Ubuntu 14.04 SSD работают из коробки, опция discard автоматом прописывается в fstab, кроме этого больше ничего не нужно делать.
В других дистрибутивах нужно проверять, есть ли эта опция у разделов на SSD. Стоит упомянуть, что данную опцию поддерживает только ext4. Для других ФС придется пользоваться fstrim из планировщика.

2. Таблица разделов

Не делите диски на разделы.

Для домашнего компьютера это бессмысленно и вредно. На SSD у вас должен быть один раздел для корня, там у вас будет хранится система и все данные. На HDD (если нужен) у вас должен быть один раздел с точкой монтирования в /mnt (у меня /mnt/data), где будут хранится большие малоиспользуемые данные (фильмы, музыка, игры). НЕ НУЖНО делать HDD точкой монтирования /home, так как в /home 99% программ хранит свои данные и постоянно к ним обращается, поэтому /home должен быть на SSD.

Повторюсь кратко: на SSD у вас должно быть все, к чему система постоянно обращается (пишет/читает)!

Не слушайте вредных советов по вынесению таких данных на HDD, как уже было сказано проблемы износа SSD нет, это миф, и большое число циклов записи вообще не влияет на долговечность SSD. Еще раз отсылаю к стате Вадима Стеркина, там это все описано более подробно и подкреплено объяснениями.

Насчет SWAP-раздела: он вам не нужен. Если у вас не хватает оперативной памяти, то OOM-killer будет прибивать ресурсоемкие приложения, если это происходит то докупите оперативки, благо ее цена не сильно кусается. Использование swap как расширителя оперативной памяти значительно замедляет работу компьютера. Есть много мнений, что без SWAP будут какие-то проблемы, но ИМХО, корни эти разговоров растут от Win9x и на сегодня это уже мифы, лично я не замечал никаких проблем от отказа от SWAP. Как пруф: на VPS сейчас редко увидишь подключенный SWAP и работают же как-то!
suspend-to-disk вам тоже не нужен, потому что холодный старт с SSD быстрее чем восстановление из спячки с HDD, так что пользуйтесь suspend-to-ram или выключайте компьютер полностью. Единственный плюс от свапа — возможность уйти в гибридную спячку, это когда система готовится к suspend-to-disk, но выполняет suspend-to-ram, так что позже, если все хорошо, идет простой выход из спячки, а если произошел сбой питания — то система восстановится с диска.

Я использую везде файловую систему ext4, так как с другими мне не удалось получить заметной разницы в производительности, а ext4 наиболее распространена, плюс имеются утилиты для восстановления данных (но не надейтесь на них, а делайте бэкапы). При создании используйте -T largefile или largefile4.

3. Используйте 64-битное ядро

От производительности оперативной памяти мало что зависит, от нее не увеличится FPS в играх и не станут быстрее запускаться приложения. Использование 64-битных приложений тоже не дает никакого прироста для обычных задач, только для очень специфичных математических расчетов и операций архивирования. Также, использование 64 ядра не требуется для адресации более 4 ГБ памяти, PAE позволяет адресовать до 64 ГБ памяти на 32 битной системе.

Но используя 64-битное ядро, приложения могут адресовать больше чем 4 ГБ памяти, что довольно полезно, так как иначе может возникать ситуация когда OOM-killer будет прибивать программы, хотя оперативки еще достаточно. Также на 64-битной системе можно адресовать сразу же всю физическую память, на 32 битной же все что выше

800 МБ надо постоянно ремапить, что несколько снижает скорость страничного обмена, хотя, как я уже сказал, это особо не влияет на скорость работы.

Еще замечал эффект, что OOM-killer может прибивать процессы, которые вроде бы еще не заняли 4 ГБ. У меня такое было с некоторыми играми. Проблема решилась переходом на 64 бита. Так что без 64-битного ядра уже никуда, хоть это и добавляет небольшие накладные расходы на использование памяти.

4. Используйте патсет pf-kernel

pf-kernel — это набор патчей для ядра linux, собранные украинцем Александром Наталенко (pfactum) направленные на улучшения desktop-experience linux-систем.

• Патчсет -ck с BFS
• BFQ I/O scheduler
• TuxOnIce
• UKSM

Наиболее полезными являются патчи BFS и BFQ, про которые уже очень много написано. BFQ борется с проблемой тормозов системы во время выполнения больших дисковых операций (знаменитый баг 12309, который по документам исправлено, но по факту продолжает досаждать), BFS — планировщий процессов, более подходящий для десктопной работы, чем те что идут в ядре. Например CFS, который используется по умолчанию допускает ситуацию, когда 2 процесса, которые требуют приоритет реального времени будут исполнятся на одном ядре, хотя другие ядра заняты низкоприоритетными задачами. Естественно, такое поведение приводит к глобальным тормозам. Зато «честный планировщик». BFS не такой «честный», но зато намного более приближен к реалиям настольных компьютеров с небольшим (большое — это 4096) количеством ядер.

Для установки, я качаю с kernel.org необходимую версию ядра без стабилизационнх патчей и накладываю на него pf-kernel. В общем случае это выглядит так:

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

Вот, например, скриншот htop при работе Dota 2 + The Sims 3 (multiseat):

При такой нагрузке на третьем экране можно спокойно работать и 25% (в 5-минутном окне по данным load-average) перегрузка CPU даже не чувствуется. Хотя, конечно, проц надо менять 🙁

5. Тюнингуйте ядро!

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

Так что делайте make xconfig

Я расскажу о наиболее важных опциях для оптимизации

Выключаем preemption, устанавливаем низкую частоту таймера и выключаем dynticks!

ДА! Мы действительно, даже вопреки документации к BFS отключаем «жизненно важные» опции для повышения отзывчивости системы. А причина в том что они — устарели, толку от них никакого и к тому же preemption негативно влияет на производительность.

Было время, когда у меня был одноядерный процессор, тогда еще в готовых ядрах не включали preemption и высокочастотный таймер, вот тогда, после включения этих опций был огромный эффект. А именно, тяжеловесное приложение, занимающее 100% CPU, даже при наличии дискового ввода-вывода и нехватке ОЗУ никак не влияло на интерактивность и отзывчивость. В те времена, еще кроме WinXP ничего не было, а подробно рассказывать как ужасно себя ведет XP в таких ситуациях, думаю, не надо, она обычно намертво виснет, заставляя тянуться к кнопке reset. Так что иметь систему, которая почти никогда не тормозит и не зависает было приятно.

Но те времена прошли, многоядерные процессоры и огромные объемы памяти сами по себе решают проблемы отзывчивости под нагрузкой, так что дополнительно решать их программными средствами не только бесполезно, но и вредно.

Так что идем в Processor type and features и выбираем для параметра Preemption Model значение No Forced Preemption (Server). Не пугаемся фразы «ocasional longer delays are possible» потому что данную проблему у нас эффективно решает BFS и многоядерный процессор. Как и написано в описании, мы выигрываем в «raw processing power».

Также, в целях оптимизации, для параметра Processor family выберите свой процессор.

Далее, устанавливаем для параметра Timer frequency значение 300 HZ. 100 все же будет маловато, да и смысла особого нет (читайте в описании почему), но вы можете поэкспериментировать. Также, 300 Гц нацело делится и на 25 и 30, что является типичными частотами для видео, это вносит свой вклад в борьбу с тирингом (это из хелпа. По факту, с тирингом успешно борется только тройная буферизация + vsync).

В этом разделе есть немало интересных опций, посмотрите, например можно выключить hot-plug для cpu и памяти, так как на десктопе это просто невозможно сделать (а выключать-включать на лету ядра редко кому нужно).

Так как у меня не ноутбук, я выключаю все что связано с энергосбережением, то есть к примеру выключаю поддержку CPU Frequency scaling вообще.

Теперь отключим динамический таймер. Не уверен точно, так как не проверял конкретно, но похоже именно эта опция приводит к постоянным «подергиваниям» на некоторых видео и особенно в играх. Так что идем General setup -> Timers subsystem и для опции Timer tick handling выбираем Periodic timer ticks (constant rate, no dynticks).

По умолчанию BFQ выключен и его надо включить а также выбрать используемым по умолчанию.

Идем Enable the block layer -> IO Schedulers включаем опции BFQ I/O scheduler и BFQ hierarchical scheduling support, для опции Default I/O scheduler выбираем, очевидно, BFQ.

6. Prelink

Можно предварительно связать с исполняемыми файлами динамические библиотеки, что позволяет еще более уменьшить время запуска приложений. По этой теме есть отдельная статья от peter23.

7. Заключение

Самое главное, что я всегда замечаю — после наложения патчсета и тюнинга ядра уходят «подергивания» в играх. Чем слабее железо, тем заметнее эти подергивания, хотя у меня есть подозрения что это все же какая-то проблема в драйверах nVidia, потому что разные версии ведут себя по-разному.

Ради пруфов решил провести тесты с помощью Geekbench 3 из Steam и gputest, результаты которых немного странные:

3.14-pf:
Single-Core Score 2421
Multi-Core Score 8209
gputest: 3720 pts, 62 FPS

3.13-generic:
Single-Core Score 2646
Multi-Core Score 8414
gputest: 3713 pts, 61 FPS

Windows:
Single-Core Score 2572
Multi-Core Score 8242
gputest: 3634 pts, 60 FPS

Как видно, почему-то на «оптимизированный» вариант в тесте CPU набирает меньше попугаев, а в тесте GPU — больше. Только сейчас я заметил что тестировал разные ядра, возможно в этом и причина различий результатов. Как будет время, проведу эти же тесты на 3.16, надеюсь, удастся найти причину. Самое же веселое тут в том, что у Windows результаты хуже, особенно в 3D значительно.

Источник