LINUX.ORG.RU

LUKS2 на ноутбуке. Медленно...

 , , , ,


0

3

Привет всем!

Есть LUKS контейнер поверх LVM, который поверх SSD NVMe.

Зарядка подключена.
Простое последовательное чтение из контейнера после открытия. Это не самая плохая скорость, бывает медленнее:

# dd if=/dev/mapper/luksdec of=/dev/null bs=1M count=4096 status=progress iflag=direct
3570401280 bytes (3,6 GB, 3,3 GiB) copied, 3 s, 1,2 GB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 3,58959 s, 1,2 GB/s

Логический том под ним:
# dd if=/dev/mapper/990provg-luksenc of=/dev/null bs=1M count=4096 status=progress iflag=direct
3235905536 bytes (3,2 GB, 3,0 GiB) copied, 1 s, 3,2 GB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 1,32352 s, 3,2 GB/s

Просто сам SSD:
# dd if=/dev/disk/by-id/nvme-Samsung_SSD_990_PRO_2TB_S6Z2NJ0TB46146F of=/dev/null bs=1M count=4096 status=progress iflag=direct
3245342720 bytes (3,2 GB, 3,0 GiB) copied, 1 s, 3,2 GB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 1,31947 s, 3,3 GB/s

Тестирование:
# cryptsetup benchmark --cipher aes-xts 
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      4481,7 MiB/s      4473,6 MiB/s


Выдёргиваю зарядку.
Контейнер:
# dd if=/dev/mapper/luksdec of=/dev/null bs=1M count=4096 status=progress iflag=direct
4126146560 bytes (4,1 GB, 3,8 GiB) copied, 10 s, 413 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 10,4032 s, 413 MB/s

Да, понятно, что процессор снижает частоту без провода. Но уж что-то показания совсем жуть. Опять тестирование:
# cryptsetup benchmark --cipher aes-xts 
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1172,1 MiB/s      1175,1 MiB/s

Вот такая ерунда. Всё это происходит на:
# lscpu 
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 7 5800H with Radeon Graphics
    CPU family:          25
    Model:               80
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            0
    Frequency boost:     enabled
    CPU max MHz:         4462,5000
    CPU min MHz:         1200,0000
    BogoMIPS:            6387.93
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_go
                         od nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy sv
                         m extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate
                          ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc c
                         qm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
                          pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    4 MiB (8 instances)
  L3:                    16 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:         
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

# free
               total        used        free      shared  buff/cache   available
Mem:        32716960     5126216    23894376      252784     3696368    26892696
Swap:       16777212           0    16777212

# uname -a
Linux lsh-ubu 6.2.1-060201-generic #202302251141 SMP PREEMPT_DYNAMIC Sat Feb 25 11:49:50 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux


Пробовал и на более старом 5.17 - аналогично. Система в это время ничего не делала, браузер с ЛОРом, терминал, пара мессенджеров.

А все говорят, что LUKS на производительность влияет очень незначительно. Что-то у меня непохоже на «незначительно». Может надо явно какую-нибудь аппаратную поддержку включить или ещё что?

Спасибо!

★★★★★

Последнее исправление: ls-h (всего исправлений: 1)

Любопытно. На моем 5800X (память 3600):

[twilightcat@silent ~]$ cryptsetup benchmark
# Тесты, использующие практически только память (без ввода-вывода на хранилище).
PBKDF2-sha1      2792479 итераций в секунду для 256-битного ключа
PBKDF2-sha256    5269226 итераций в секунду для 256-битного ключа
PBKDF2-sha512    2129088 итераций в секунду для 256-битного ключа
PBKDF2-ripemd160 1110779 итераций в секунду для 256-битного ключа
PBKDF2-whirlpool  860899 итераций в секунду для 256-битного ключа
argon2i      15 итераций, 1048576 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)
argon2id     15 итераций, 1048576 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)
#     Algorithm |       Key |      Encryption |      Decryption
#      Алгоритм |      Ключ |      Шифрование |     Расшифровка
        aes-cbc        128b      1562,6 MiB/s      6809,4 MiB/s
    serpent-cbc        128b       148,2 MiB/s      1063,9 MiB/s
    twofish-cbc        128b       296,9 MiB/s       549,4 MiB/s
        aes-cbc        256b      1166,6 MiB/s      5484,1 MiB/s
    serpent-cbc        256b       147,9 MiB/s      1064,6 MiB/s
    twofish-cbc        256b       297,7 MiB/s       550,8 MiB/s
        aes-xts        256b      5437,3 MiB/s      5442,7 MiB/s
    serpent-xts        256b       960,5 MiB/s       946,7 MiB/s
    twofish-xts        256b       509,6 MiB/s       509,3 MiB/s
        aes-xts        512b      4621,0 MiB/s      4569,2 MiB/s
    serpent-xts        512b       957,1 MiB/s       951,7 MiB/s
    twofish-xts        512b       510,7 MiB/s       518,6 MiB/s
pekmop1024 ★★★★★
()

И туда же:

[twilightcat@silent ~]$ dd if=/dev/mapper/linux.root of=/dev/null bs=1M count=4096 status=progress iflag=direct
3703570432 байтов (3,7 GB, 3,4 GiB) скопировано, 3 s, 1,2 GB/s
4096+0 записей получено
4096+0 записей отправлено
4294967296 байтов (4,3 GB, 4,0 GiB) скопировано, 3,49485 s, 1,2 GB/s

[twilightcat@silent ~]$ dd if=/dev/nvme0n1p4 of=/dev/null bs=1M count=4096 status=progress iflag=direct
2418016256 байтов (2,4 GB, 2,3 GiB) скопировано, 1 s, 2,4 GB/s
4096+0 записей получено
4096+0 записей отправлено
4294967296 байтов (4,3 GB, 4,0 GiB) скопировано, 1,74714 s, 2,5 GB/s

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

https://blog.cloudflare.com/speeding-up-linux-disk-encryption/

О как.

TL;DR - кина не будет, все так и должно быть. До того, как CF немного разгреб это, было вообще в два раза медленнее, чем есть. Чего, впрочем, для ноутбука более чем, если нет специфических задач, конечно.

pekmop1024 ★★★★★
()
Последнее исправление: pekmop1024 (всего исправлений: 1)
Ответ на: комментарий от Aber

Попробуй запустить в цикле:

# while true; do cryptsetup benchmark --cipher aes-xts; done
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1287,5 MiB/s      1292,8 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1308,0 MiB/s      1335,9 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1302,5 MiB/s      1303,8 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1325,9 MiB/s      1305,5 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1308,6 MiB/s      1302,7 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1307,2 MiB/s      1302,0 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1311,4 MiB/s      1317,9 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1295,4 MiB/s      1333,7 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1316,0 MiB/s      1314,3 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1297,1 MiB/s      1316,7 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1324,1 MiB/s      1303,4 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1321,1 MiB/s      1314,7 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1221,7 MiB/s      1292,3 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1330,7 MiB/s      1326,4 MiB/s
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1288,6 MiB/s      1316,6 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1299,7 MiB/s      1322,7 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1316,0 MiB/s      1330,5 MiB/s
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1294,3 MiB/s      1364,6 MiB/s
# Tests are approximate using memory only (no storage IO).


Не знаю, может надо 2 часа ждать. За примерно 3 минуты ничего не изменилось. Ноут на проводе.

ls-h ★★★★★
() автор топика
Ответ на: комментарий от pekmop1024

Статью по ссылке все цитируют, но никто не сподобился прочитать.
Дешманский 1165 + дешманский SN730 + ядро 4.18:
ЧЯДНТ?

fio --numjobs=8 --readonly --size=10G --direct=1 --verify=0 --bs=1M --rw=read --group_reporting=1 --filename=/dev/mapper/rhel_t14s-home --name=t1
...

   READ: bw=3018MiB/s (3164MB/s), 3018MiB/s-3018MiB/s (3164MB/s-3164MB/s), io=80.0GiB (85.9GB), run=27147-27147msec
 fio --numjobs=1 --readonly --size=10G --direct=1 --verify=0 --bs=1M  --rw=read --group_reporting=1 --filename=/dev/mapper/rhel_t14s-home --name=t1
...

   READ: bw=698MiB/s (732MB/s), 698MiB/s-698MiB/s (732MB/s-732MB/s), io=10.0GiB (10.7GB), run=14660-14660msec

fio --numjobs=8 --readonly --size=10G --direct=1 --verify=0 --bs=1M  --rw=read --group_reporting=1 --filename=/dev/nvme0n1p6 --name=t1
...

   READ: bw=3045MiB/s (3193MB/s), 3045MiB/s-3045MiB/s (3193MB/s-3193MB/s), io=80.0GiB (85.9GB), run=26899-26899msec

i586 ★★★★★
()
Ответ на: комментарий от pekmop1024

Это риторический вопрос.

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

ТС, вы понимаете, что

# dd if=/dev/disk/by-id/nvme-Samsung_SSD_990_PRO_2TB_S6Z2NJ0TB46146F of=/dev/null bs=1M count=4096 status=progress iflag=direct

–тоже не в один поток читает?

Тестируя с помощью dd вы не контролируете количество потоков, но результат от этого зависит кратно.

i586 ★★★★★
()
Последнее исправление: i586 (всего исправлений: 1)

Ryzen 3550H + 32GB DDR4-2400 + Samsung SSD 970 EVO Plus
Ubuntu 20.04 (kernel 5.15)

AC on:

sudo dd if=/dev/mapper/home_ct of=/dev/null bs=1M count=4096 status=progress iflag=direct
4139778048 байт (4,1 GB, 3,9 GiB) скопирован, 5 s, 828 MB/s
4096+0 записей получено
4096+0 записей отправлено
4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 5,23906 s, 820 MB/s

sudo dd if=/dev/nvme0n1p1 of=/dev/null bs=1M count=4096 status=progress iflag=direct
100+0 записей получено
100+0 записей отправлено
104857600 байт (105 MB, 100 MiB) скопирован, 0,0442731 s, 2,4 GB/s

AC off:

sudo dd if=/dev/mapper/home_ct of=/dev/null bs=1M count=4096 status=progress iflag=direct
4245684224 байт (4,2 GB, 4,0 GiB) скопирован, 7 s, 606 MB/s
4096+0 записей получено
4096+0 записей отправлено
4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 7,0754 s, 607 MB/s

sudo dd if=/dev/nvme0n1p1 of=/dev/null bs=1M count=4096 status=progress iflag=direct
100+0 записей получено
100+0 записей отправлено
104857600 байт (105 MB, 100 MiB) скопирован, 0,0443349 s, 2,4 GB/s

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от pekmop1024

У меня результат dd и fio c одним потоком совпадают.

Могут совпадать, могут не совпадать. Чтение с физического устройства, конечно, идет в один поток. Шифрование – в n потоков, количество которых много от чего зависит. Поэтому такие тесты показывают погоду на Марсе.

Откуда

Трассировкой.

i586 ★★★★★
()
Ответ на: комментарий от Aber

А может у тебя процессор скидывает частоту и планировщик не хочет её сразу бустить?

Обновил систему до 22.10. Теперь зависимость стала более понятная.
1. Если ноутбук был загружен на проводе, провод не вынимался, и тест проводится на проводе, то скорости высокие, какие и должны быть.
2. Если в какой-то момент от начала загрузки и до тестирования ноутбук побывал на батарейке, то скорости печальные.

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

Куда копать? TLP пока выключил. Что ещё контролирует производительность и батарейку?

ls-h ★★★★★
() автор топика