Пропали 4 потока CPU в Kali linux

Kali linux. После очередных обновлений замечаю, что в верхней части, где загрузка CPU и "полосочки" с загрузкой по каждому из потоков 4х ядер процессора (у меня 8 потоков на 4 ядра), вместо 8-ми этих самих "полосочек" стало показываться только 4!!!

Изучение форумов ответа не дало, возможно новая проблема. Вот вывод:

└─$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-3
Off-line CPU(s) list: 4-7 <<<<<<<<<<<<<<<<<< !!!!!!!!!!!!!!!!!!!!!!!!!!
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
CPU family: 6
Model: 142
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Stepping: 10
CPU(s) scaling MHz: 38%
CPU max MHz: 3400,0000
CPU min MHz: 0,0000
BogoMIPS: 3600,00

Биос не правил.
После этого беру live дистрибутив, загружаюсь с него и вижу:

└─$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
Остальное аналогично.

Вывод: если стандартная система отличается от live версии только программной частью (биос не изменялся), и при live версии видны все 8 потоков, то дело в программной части основной системы kali linux.

Вопрос: кто отключил 2 ядра (или 4 потока, по одному в каждом ядре)?
И самое главное, как включить их обратно?

0

Сделал тест скорости

dd if=/dev/zero of=testfile bs=512 count=5000000

Результаты:
normal (4 потока):
5000000+0 records in
5000000+0 records out
2560000000 bytes (2,6 GB, 2,4 GiB) copied, 37,9667 s, 67,4 MB/s


safemode (8 потоков):
5000000+0 records in
5000000+0 records out
2560000000 bytes (2,6 GB, 2,4 GiB) copied, 31,4026 s, 81,5 MB/s

Продолжаю искать рецепт

Добавлено через 24 минуты
Оно вроде при тесте загружает полностью только один поток, что видно вверху экрана по зеленой полоске (общая загрузка при normal 25%, при safemode 12.5%).

Но результат по цифрам показывает, что все-таки 8 потоков немного быстрее, чем 4.

0

Итак, вопрос решен!!!

Если кратко, то добавил в автозагрузку параметр echo on > /sys/devices/system/cpu/smt/control
и теперь вижу все 8 потоков сверху справа на индикаторе загрузки системы. Общая загрузка также упала (ведь "появились" еще 4 потока

Это кратко.

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

Как я до этого "дошел":
в файле
cat /sys/devices/system/cpu/smt/control
был параметр off
поэтому 4 потока не работали.

Нужно было дать в этот файл параметр on

Но просто команда
sudo echo on > /sys/devices/system/cpu/smt/control
не приводила к успеху, не было необходимых прав доступа.

Однако команды
sudo -i
sudo echo on > /sys/devices/system/cpu/smt/control
cat /sys/devices/system/cpu/smt/control
on
давали нужный результат.

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

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

Возможно, суждение о том, что параметр nosmt в
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.19.0-kali2-amd64 root=UUID=5a0045bc-e3b4-4b3b-9a7c-311726081560 ro quiet splash mitigations=auto l1tf=flush kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt
являлся критическим, не было верным, и нужно было пытаться не избавиться от параметра nosmt в загрузчике grub, а просто включить контроль smt, как написано выше.

Дальнейшие действия были следующие:
lscpu
смотрим, сколько потоков работают, сколько offline (было 4 online, 4 offline).

Смотрим, с какими параметрами загружается система через загрузчик grub
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.19.0-kali2-amd64 root=UUID=5a0045bc-e3b4-4b3b-9a7c-311726081560 ro quiet splash mitigations=auto l1tf=flush kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt
Это сейчас у меня такие параметры. Ранее, когда только начинал разбираться, были чуть другие (см. начальные сообщения, но при этом параметр nosmt был (думал, что он мешает работе 8 потоков).

Смотрим дальше
cat /sys/devices/system/cpu/smt/control
off
Выключено. Работают 4 потока. Включаем все 8:
sudo -i
sudo echo on > /sys/devices/system/cpu/smt/control
cat /sys/devices/system/cpu/smt/control
on
Если делать без sudo -i, просто от sudo, то выдает ошибку и не работает.

Создание скрипта:

sudo mousepad /etc/init.d/cpu8
Я использую редактор mousepad, кому нравится другой - используйте его.
Это создаем файл cpu8 в указанной директории.

Вот его содержимое:
#! /bin/sh

### BEGIN INIT INFO
# Provides: cpu8
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: cpu8
### END INIT INFO

echo on > /sys/devices/system/cpu/smt/control

Содержимое закончилось
Сначала создал файл без комментариев, но потом получил ошибку, что нужно добавить Default-Start, поэтому содержание такое.

Делаем файл исполняемым:
sudo chmod +x /etc/init.d/cpu8

Смотрим, что у нас система systemd или другая, для чего запускаем:
ps -p 1 -o comm=
Получаем:
systemd

Создаем файл:
sudo mousepad /etc/systemd/system/cpu8.service

со следующим содержимым:
[Unit]
Description=cpu8 service
# After=network.target
[Service]
ExecStart=/etc/init.d/cpu8
[Install]
WantedBy=multi-user.target

Конец файла.

Пробуем запустить и посмотреть, запустились ли 8 потоков:
sudo systemctl start cpu8
Потом:
lscpu
У меня запустились.
Вместе с тем, нужно отметить, что индикатор загрузки процессора "упал", но все 8 "зелененьких полосочек" не отобразились. Думаю, они формируются при загрузке самой системы.

Замем нужно сделать это загружаемым в самой системе каждый раз. Запускаем как службу:
sudo systemctl enable cpu8

После перезагрузки 8 "зелененьких полосочек" живенько перекликаются, общая загрузка практически "лежит" на минимуме
Что, собственно, и хотелось получить.

Да, еще один момент:
вместе с тем, что
cat /proc/cmdline
выдает:
BOOT_IMAGE=/boot/vmlinuz-5.19.0-kali2-amd64 root=UUID=5a0045bc-e3b4-4b3b-9a7c-311726081560 ro quiet splash mitigations=auto l1tf=flush kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt
вот вывод команды
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
CPU family: 6
Model: 142
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Stepping: 10
CPU(s) scaling MHz: 42%
CPU max MHz: 3400,0000
CPU min MHz: 400,0000
BogoMIPS: 3600,00
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 art arch_perfmon
pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monit
or ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcn
t tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb
invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgs
base tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt
xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_
epp md_clear flush_l1d arch_capabilities
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 6 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-7
Vulnerabilities:
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Meltdown: Mitigation; PTI
Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Retbleed: Mitigation; IBRS
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS Not affected
Srbds: Mitigation; Microcode
Tsx async abort: Not affected

Нужно обратить внимание на параметр SMT vulnerable, ранее он был off.

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

0