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)

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

У тебя и есть «незначительно». Производительность - это не скорость чтения с диска, а скорость работы софта на компе. В диск редко что-то заметно упирается, поэтому что 4ГБ/с что 400МБ/с разницы особой не заметишь в бытовом использовании. Да и вообще, большинство бытовых ссд как раз около 400МБ/с и дают. А жёсткие диски и того меньше (около 100), но тормознутость у них ощущается не из-за этого, а из-за времени позиционирования головок, из-за которого реальная скорость чтения случайных данных получается уже ниже 10МБ/с часто. Вот когда LUKS тебе просадит скорость до 10МБ/с - тогда да, он «значительно» влиять будет.

Но тем не менее не исключено что с какой-нить аппаратной поддержкой AES будет быстрее.

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

А если bs=4G? :)

# dd if=/dev/mapper/luksdec of=/dev/null bs=4G count=10 status=progress iflag=direct
2147479552 bytes (2,1 GB, 2,0 GiB) copied, 5 s, 461 MB/s
dd: warning: partial read (2147479552 bytes); suggest iflag=fullblock
21474795520 bytes (21 GB, 20 GiB) copied, 39 s, 546 MB/s 
0+10 records in
0+10 records out
21474795520 bytes (21 GB, 20 GiB) copied, 39,3384 s, 546 MB/s
ls-h ★★★★★
() автор топика
Ответ на: комментарий от firkax

У тебя и есть «незначительно»

В разы это незначительно?

Производительность - это не скорость чтения с диска

У меня файлы большие, видео. Я на них много чего тестирую.

Да и вообще, большинство бытовых ссд как раз около 400МБ/с и дают.

Точно? У меня даёт 3,2 GB/s, как можно видеть в выводе dd.

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

Но тем не менее не исключено что с какой-нить аппаратной поддержкой AES будет быстрее.

В процессоре же есть, см. флаги. Может быть надо что-то явно включить?

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

В разы

Ты бы ещё с рамдиском сравнил, было бы в сотни раз.

У меня файлы большие, видео. Я на них много чего тестирую.

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

У меня даёт 3,2 GB/s,

Так у тебя и не обычный ссд а что-то мажорское. На ссд 400МБ/с LUKS был бы те же 400МБ/с, то есть вообще не уменьшил бы скорость. Но твой дись слишком быстрый.

В процессоре же есть, см. флаги. Может быть надо что-то явно включить?

Не в курсе. https://bbs.archlinux.org/viewtopic.php?id=160452 Тут пишут что само включается.

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

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

Вкратце: монтировать dm-crypt с флагами no_read_workqueue и no_write_workqueue, а также можно применить патч ядра, чтобы ускорить шифрование:

https://github.com/cloudflare/linux/blob/master/patches/0024-Add-xtsproxy-Crypto-API-module.patch

ValdikSS ★★★★★
()

А нафига шифрованный раздел использовать под огромные видеофайлы? Я только home зашифровал, а всякий хлам у меня отдельно хранится, на не шифрованном разделе в /storage, там фотки, видео, торренты.


Just FYI:

CPU: AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Supports: aes

AC:

cryptsetup benchmark --cipher aes-xts 
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      2425,7 MiB/s      2555,1 MiB/s

Battery:

cryptsetup benchmark --cipher aes-xts 
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1482,8 MiB/s      1495,9 MiB/s
Aber ★★★★★
()
Ответ на: комментарий от firkax

Так у тебя и не обычный ссд а что-то мажорское.

Так я и хочу это использовать на соответствующих скоростях. Нормальные скорости при PCI-e NVMe это 4000+ MB/sec. А ты мне про HDD рассказываешь и 10 MB :-)

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

warning: partial read
0+10 records in

При чтении большими блоками все же должно быть больше. bs=100M должно работать нормально.

1.2GBps легко объяснимо, т.к. блоки читаются и декриптуются последовательно. Должно быть примерно 3.2*4.4/(3.2+4.4)=1.8.

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

Каком бенчмаркинге, какой один поток? Внутренние workqueue в dm-crypt неэффективны для аппаратно ускоренного шифрования, поэтому их следует отключить, а патч добавляет синхронный AES-XTS с минимальным оверхедом, который работает быстрее асинхронного текущего.

ValdikSS ★★★★★
()

У тебя проблемы с пониманием происходящего (большие). Итак, поехали:

Начнем с теста шифрования. Твой тест дрянь. Дело в том, что каждый блок на диске шифруется независимо, а твой тест потоковый. И вот эти вот все IV и связанные с ним операции твой стримовый тест не учитывает. А это немало, на самом деле. Ну и плюс к тому, ядро по техническим причинам некоторые операции мегаоптимизированным способом выполнить не может. То есть там по постановке относительно твоего теста скорость ниже процентов на 25-30.

Затем у тебя проблемы с математикой.

Предположим, твой днищекомпьютер шифрует 3.6ГБ/с (это от твоих 4.4 отнимем 20%) и читает 3.3ГБ/с. Тогда он читает 1.2 гигабайта за 0.4 секунды и потом расшифровывает их еще за 0.33 секунды

Итого 0.75 секунд на 1.2ГБ. А значит, гипотетическая (идеальная в сферическом вакууме!!!) производительность твоего стека составляет 1.6ГБ/с

no-dashi-v2 ★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 2)
Ответ на: комментарий от no-dashi-v2

Да. Если тестировать нормально, будет минимальный оверхед.

ТС, можете еще попробовать fio --numjobs=8 --readonly --size=10G --direct=1 --verify=0 --bs=1M --iodepth=64 --rw=read --group_reporting=1.

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

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

Проблема может быть вызвана неправильным выравниванием разделов, lvm и файловой системы. На одном из моих дисков команда определения оптимального размера раздела выдавала неправильное значение (optimal_size_transfer) внутри /sys был какой-то рандомный, из-за чего lvm и фс неправильно применяли настройки. Стоит проверить это значение и заодно выравнивание всего стэка диска.

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

И много людей шифруют весь диск?

Да, ведь так тупо проще.

Реально настроили trust chain с использованием TPM?

Обычно нет, по причине недоверия этому самому TPM.

А как ты решил, что одно должно вытекать из другого?

token_polyak ★★★★
()
Ответ на: комментарий от no-dashi-v2

Дак, как я понимаю, 1,2Гб/с устраивает ТС, его не устраивает снижение скорости при отключеном ЗУ.

Твой тест дрянь.

Ну он и «cryptsetup benchmark» сравнивает с подключеным и отключеным ЗУ.

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

Я всегда шифрую. Trust chain не настраивал, потому что от наркомана Пети, который может утащить мой ноут, чтобы продать на Авито, этого уже достаточно, чтобы не ушла моя почта, финансовые данные, и исходники проектов, над которыми я работаю (достаточно известные проекты, используемые десятками миллионов людей по всему миру).

emorozov
()
Ответ на: комментарий от mky

Он пишет: «А все говорят, что LUKS на производительность влияет очень незначительно. Что-то у меня непохоже на «незначительно»».

Так что жалуется он именно на LUKS

no-dashi-v2 ★★
()
Ответ на: комментарий от no-dashi-v2

Дело в том, что каждый блок на диске шифруется независимо, а твой тест потоковый. И вот эти вот все IV и связанные с ним операции твой стримовый тест не учитывает.

ты раз знаешь умные слова вроде IV, узнал бы заодно что такое xts, чтобы глупости не писать

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

И чо? Это как-то отменяет тот факт, что в ядре на каждый запрос надо выполнять тонну операций связанных со всякими аллокациями контекста и копированиями данных, каковые в юзерспейсном тесте можно просто игнорировать и реюзать статически выделенные области?

no-dashi-v2 ★★
()
Ответ на: комментарий от Aber

Реально настроили trust chain с использованием TPM?

Нет. У меня цель этого всего такая: спёрли ноутбук (или потерял где) - мои личные данные, логин и пароль от ЛОРа остались недоступны для посторонних. И рабочие данные в сохранности. Там нет чертежей подводных летающих тарелок или рецептов философского камня, товарищу майору я не интересен. Поэтому /boot у меня останется в открытом виде, а вот остальной SSD я хотел весь положить в LUKS. Так проще, чем думать, что надо, а что не надо шифровать.

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

А как ты решил, что одно должно вытекать из другого?

Я так думал что это же защита от компрометации, когда у тебя похищают ноут, ставят кейлогер куда-то EFI или boot, по тихому возвращают, ты ничего не заметил, ввел пароли для доступа к дискам. В следующий раз у тебя уже уводят ноут навсегда, с чертежами подводных лодок :)
Вот тут вроде TPM2 с chain-of-trust может спасти ситуацию, а от случайной утери вполне спасает даже шифрованный home.

Я шифрую один раздел /home, у меня нет оверхедов на доступ к корню, включая /usr или /var где находятся пакетные кеши, базы данных и докер контейнеры, там никаких продакшен паролей нету. И скорость доступа нативная. Не говоря уже про фильмы которые уж точно шифровать не нужно, а объемы у них по 5-10Gb каждый.

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

потому что от наркомана Пети, который может утащить мой ноут, чтобы продать на Авито, этого уже достаточно

Тоже не доверяешь Поттерингу ? ;)

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

Я так думал что это же защита от компрометации, когда у тебя похищают ноут, ставят кейлогер куда-то EFI или boot, по тихому возвращают, ты ничего не заметил, ввел пароли для доступа к дискам. В следующий раз у тебя уже уводят ноут навсегда, с чертежами подводных лодок :) Вот тут вроде TPM2 с chain-of-trust может спасти ситуацию, а от случайной утери вполне спасает даже шифрованный home.

Я не очень понял каким образом TPM спасает от кейлогера в EFI.

А вообще, если у кого-то серьезного возникнет задача спереть чертежи подводных лодок, окажись они на ноутбуке, обойдутся кучей других способов, если есть возможность по тихому добраться до ноута. Даже оставаясь в чисто технических рамках. Аппаратные жучки и всякий там ТЕМPEST/ПЭMИH никто не отменял.

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

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

Я не очень понял каким образом TPM спасает от кейлогера в EFI.

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

Аппаратные жучки

Согласен.

Короче по этой причине не понимаю зачем страдать с шифровкой всего диска, понятное дело что будет оверхед на доступ к данных, я считаю что надо шифровать только то что важно, а важно много, но не все. Кеш браузера важен, там cookie и пароли. Keystore’ы DE тоже нужны, .ssh и всякое такое. Но блин шифровать весь диск… мне кажется это для параноиков, и уж они то точно знают что им важнее зашифровать все чем скорость работы I/0 диска. Ничего не бывает бесплатно.

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

Стоит проверить это значение и заодно выравнивание всего стэка диска.

Мне где-то попадалось, что поскольку SSD от Samsung о себе сообщает как об устройстве с блоками по 512, то работает неэффективно. А вот если использовать по 4К, то должно стать лучше. Но у меня между SSD и LUKS ещё есть LVM. Сообщает ли он выше размер блока от самого SSD? Надо разобраться...

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

Но блин шифровать весь диск… мне кажется это для параноиков

Зашифровать весь проще, чем думать где у тебя лежат данные браузера, а где лежат ключи SSH и т.п.

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

Вкратце: монтировать dm-crypt с флагами no_read_workqueue и no_write_workqueue

Или я чего-то не понимаю, или эффект тут обратный.

root@lsh-ubu:~# cryptsetup open /dev/mapper/990PRO-uroot--enc uroot-dec 
Enter passphrase for /dev/mapper/990PRO-uroot--enc: 
root@lsh-ubu:~# dd if=/dev/mapper/uroot-dec of=/dev/null bs=1M status=progress 
107313364992 bytes (107 GB, 100 GiB) copied, 106 s, 1,0 GB/s
102384+0 records in
102384+0 records out
107357405184 bytes (107 GB, 100 GiB) copied, 111,438 s, 963 MB/s
root@lsh-ubu:~# cryptsetup close uroot-dec

root@lsh-ubu:~# cryptsetup open --perf-no_read_workqueue --perf-no_write_workqueue /dev/mapper/990PRO-uroot--enc uroot-dec
Enter passphrase for /dev/mapper/990PRO-uroot--enc: 
root@lsh-ubu:~# dd if=/dev/mapper/uroot-dec of=/dev/null bs=1M status=progress 
106996695040 bytes (107 GB, 100 GiB) copied, 125 s, 856 MB/s
102384+0 records in
102384+0 records out
107357405184 bytes (107 GB, 100 GiB) copied, 130,877 s, 820 MB/s
root@lsh-ubu:~# 

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

У тебя и есть «незначительно»

Вот человек жалуется, что у него медленно это 4485.14 MB/s https://forum.manjaro.org/t/luks-makes-ssd-slow/89114
А у меня в лучшем случае 1.2 GB/s максимум.

Такое впечатление, что половина ЛОРчан тут на HDD сидит и NVMe вообще не использовали.

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

Ну надо же понимать, что шифрование не бесплатно, на него тратятся вычислительные ресурсы. А гигабайты в секунду - это весьма огромная скорость. NVMe думаю и правда мало у кого есть. Большинству такие скорости реально не нужны.

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

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

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       740519 iterations per second for 256-bit key
PBKDF2-sha256    1456355 iterations per second for 256-bit key
PBKDF2-sha512     606113 iterations per second for 256-bit key
PBKDF2-ripemd160  297215 iterations per second for 256-bit key
PBKDF2-whirlpool  236592 iterations per second for 256-bit key
argon2i       4 iterations, 1000544 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 1021705 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       400,2 MiB/s      1524,8 MiB/s
    serpent-cbc        128b        40,1 MiB/s       279,0 MiB/s
    twofish-cbc        128b        78,2 MiB/s       144,2 MiB/s
        aes-cbc        256b       304,4 MiB/s      1275,7 MiB/s
    serpent-cbc        256b        40,9 MiB/s       279,0 MiB/s
    twofish-cbc        256b        78,3 MiB/s       144,9 MiB/s
        aes-xts        256b      1311,2 MiB/s      1299,6 MiB/s
    serpent-xts        256b       250,4 MiB/s       249,1 MiB/s
    twofish-xts        256b       138,9 MiB/s       135,4 MiB/s
        aes-xts        512b      1099,3 MiB/s      1089,8 MiB/s
    serpent-xts        512b       252,4 MiB/s       248,8 MiB/s
    twofish-xts        512b       139,1 MiB/s       139,9 MiB/s

Для сравнения, например: https://forum.manjaro.org/t/luks-makes-ssd-slow/89114/7

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

По ссылке у пользователя linux-aarhus

aes-xts        256b      4394,8 MiB/s      4427,0 MiB/s
aes-xts        512b      3620,4 MiB/s      3612,7 MiB/s

У человека спросили, а что у него за система, его ответ:

...
Intel Core i9-9900K bits
...
BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64 root=UUID=de... rw mitigations=off

т.е. этот человек вырубает патчи на уязвимости в CPU.

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

Попробуй стартовать ядро с mitigations=off и замерь производительность.

Что-то не особо помогает:

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-6.2.1-060201-generic root=/dev/mapper/Ubuntu-root ro amdgpu.audio=0 mitigations=off

# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       684449 iterations per second for 256-bit key
PBKDF2-sha256    1358259 iterations per second for 256-bit key
PBKDF2-sha512     570498 iterations per second for 256-bit key
PBKDF2-ripemd160  271651 iterations per second for 256-bit key
PBKDF2-whirlpool  219919 iterations per second for 256-bit key
argon2i       4 iterations, 963296 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 971824 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       376,7 MiB/s      1484,7 MiB/s
    serpent-cbc        128b        37,3 MiB/s       261,2 MiB/s
    twofish-cbc        128b        71,5 MiB/s       134,2 MiB/s
        aes-cbc        256b       276,1 MiB/s      1103,5 MiB/s
    serpent-cbc        256b        37,6 MiB/s       236,2 MiB/s
    twofish-cbc        256b        71,3 MiB/s       128,0 MiB/s
        aes-xts        256b      1077,0 MiB/s      1056,5 MiB/s
    serpent-xts        256b       228,2 MiB/s       224,5 MiB/s
    twofish-xts        256b       129,2 MiB/s       130,3 MiB/s
        aes-xts        512b      1044,3 MiB/s      1045,2 MiB/s
    serpent-xts        512b       235,1 MiB/s       231,5 MiB/s
    twofish-xts        512b       127,2 MiB/s       128,0 MiB/s

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

Я не понял, почему в стартовом сообщении:

Так вот я и сам не понимаю, от чего это зависит. Вот сейчас проверил:

root@lsh-ubu:~# cat /sys/class/power_supply/ADP0/online 
1
root@lsh-ubu:~# cryptsetup benchmark --cipher aes-xts
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      1336,6 MiB/s      1348,4 MiB/s
root@lsh-ubu:~# date
Вт 28 мар 2023 10:47:59 MSK

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

Не говоря уже про фильмы которые уж точно шифровать не нужно, а объемы у них по 5-10Gb каждый.

вот уж от шифрования фильмов никакой проблемы точно нет или ты их смотришь на скорости 50х и гигабайта/с тебе не хватает? ))

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

Разделы не выровнены по физическим секторам? PV LVM не выровнен по разделам?

Всё выровнено. Опять же скорости бенчмарка невысокие. Непонятно...

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

Попробовал загрузить с USB самую последнюю Ubuntu. Скорости выглядят получше:

На проводе
root@ubuntu:~# cat /sys/class/power_supply/ADP0/online 
1
root@ubuntu:~# cryptsetup open /dev/mapper/990PRO-uroot--enc uroot-dec 
Enter passphrase for /dev/mapper/990PRO-uroot--enc: 
root@ubuntu:~# dd if=/dev/mapper/uroot-dec of=/dev/null bs=1M count=10240 status=progress 
9657384960 bytes (9.7 GB, 9.0 GiB) copied, 4 s, 2.4 GB/s
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 4.75066 s, 2.3 GB/s
root@ubuntu:~# dd if=/dev/mapper/990PRO-uroot--enc of=/dev/null bs=1M count=10240 status=progress 
9810477056 bytes (9.8 GB, 9.1 GiB) copied, 3 s, 3.3 GB/s
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 3.28083 s, 3.3 GB/s
root@ubuntu:~# cryptsetup benchmark 
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      2508555 iterations per second for 256-bit key
PBKDF2-sha256    4946113 iterations per second for 256-bit key
PBKDF2-sha512    2126929 iterations per second for 256-bit key
PBKDF2-ripemd160 1000549 iterations per second for 256-bit key
PBKDF2-whirlpool  791975 iterations per second for 256-bit key
argon2i       9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1413.4 MiB/s      5641.3 MiB/s
    serpent-cbc        128b       138.0 MiB/s       975.8 MiB/s
    twofish-cbc        128b       268.1 MiB/s       498.3 MiB/s
        aes-cbc        256b      1059.7 MiB/s      4609.2 MiB/s
    serpent-cbc        256b       138.0 MiB/s       972.8 MiB/s
    twofish-cbc        256b       268.0 MiB/s       497.5 MiB/s
        aes-xts        256b      4719.1 MiB/s      4731.8 MiB/s
    serpent-xts        256b       879.6 MiB/s       866.4 MiB/s
    twofish-xts        256b       472.9 MiB/s       482.8 MiB/s
        aes-xts        512b      3964.6 MiB/s      3943.9 MiB/s
    serpent-xts        512b       879.5 MiB/s       866.4 MiB/s
    twofish-xts        512b       471.7 MiB/s       481.8 MiB/s

От батареи:
root@ubuntu:~# cat /sys/class/power_supply/ADP0/online 
0
root@ubuntu:~# dd if=/dev/mapper/uroot-dec of=/dev/null bs=1M count=10240 status=progress 
10635706368 bytes (11 GB, 9.9 GiB) copied, 6 s, 1.8 GB/s
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 6.47977 s, 1.7 GB/s
root@ubuntu:~# dd if=/dev/mapper/990PRO-uroot--enc of=/dev/null bs=1M count=10240 status=progress 
5010096128 bytes (5.0 GB, 4.7 GiB) copied, 2 s, 2.5 GB/s
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 2.95439 s, 3.6 GB/s
root@ubuntu:~# cryptsetup benchmark 
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1798586 iterations per second for 256-bit key
PBKDF2-sha256    3518711 iterations per second for 256-bit key
PBKDF2-sha512    1524093 iterations per second for 256-bit key
PBKDF2-ripemd160  720175 iterations per second for 256-bit key
PBKDF2-whirlpool  574247 iterations per second for 256-bit key
argon2i       8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id     10 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1412.4 MiB/s      5631.3 MiB/s
    serpent-cbc        128b       137.9 MiB/s       973.5 MiB/s
    twofish-cbc        128b       268.0 MiB/s       498.5 MiB/s
        aes-cbc        256b      1058.0 MiB/s      4595.1 MiB/s
    serpent-cbc        256b       138.0 MiB/s       973.9 MiB/s
    twofish-cbc        256b       267.9 MiB/s       498.7 MiB/s
        aes-xts        256b      4726.6 MiB/s      4723.6 MiB/s
    serpent-xts        256b       876.5 MiB/s       864.5 MiB/s
    twofish-xts        256b       472.2 MiB/s       481.3 MiB/s
        aes-xts        512b      3917.9 MiB/s      3921.6 MiB/s
    serpent-xts        512b       876.3 MiB/s       865.0 MiB/s
    twofish-xts        512b       471.7 MiB/s       481.3 MiB/s
root@ubuntu:~# 


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

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

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

while true; do cryptsetup --cipher aes-xts; done

При работе от сети на моем Ryzen 5 3550 у меня всегда выходит:

# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      2520,8 MiB/s      2558,0 MiB/s

А этот процессор в пару раз хуже твоего.

Aber ★★★★★
()