LINUX.ORG.RU
ФорумTalks

[dm-crypt multicore] Пользователи dm-crypt могут пробовать очередной патч


0

1

http://lkml.org/lkml/2010/11/12/344

Насколько я понял, эта версия не самая оптимальная, но скорость чтения поднимает в 1.4 раза на четырёхядерном процессоре, скорость записи - до 2-х с лишним раз быстрее. Поддерживаются шифрованные разделы поверх шифрованных разделов. Да, тест в сообщении был с CFQ, говорят для dm-crypt сейчас это не самый оптимальный шедулер ввода-вывода.

★★★★★

> скорость чтения поднимает в 1.4 раза

скорость записи - до 2-х с лишним раз быстрее

на 200% быстрее! покупайте наших слонов!!!

Rastafarra ★★★★
()

скорость чтения поднимает в 1.4 раза на четырёхядерном процессоре, скорость записи - до 2-х с лишним раз быстрее

O_o У меня потеря скорости всего 5-10% по сравнению с обычными разделами. Этот патч разгоняет диск?

Поддерживаются шифрованные разделы поверх шифрованных разделов.

А раньше типа нельзя было?

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

> Этот патч разгоняет диск?

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

Предыдущий вариант этого патча как раз имел проблемы с наложенными друг на друга шифрованными разделами. Об этом в сообщении говорится, как о решённой проблеме (до 20-ти уровней вложенности)

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

Нет, просто видимо лёгкие алгоритмы шифрования и на одном ядре без проблем обсчитываются.

AMD 64 X2 4800+, AES-256 (CBC-ESSIV). Проблем нет. Модуль используется aes_x86_64. Возможно, они исправляли новые проблемы, появившиеся после 26-го ядра... В общем, УМВР и не тормозит :)

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

> В общем, УМВР и не тормозит :)

Ничего, это исправимо (злостно-умыляющийся смайлик)

Andrew-R ★★★★★
() автор топика
Ответ на: комментарий от true_admin

> ладно, пойду с другого конца. Какую скорость dd в файл у тебя показывает?

Не знаю, т.к. у меня иксы застывают намертво из-за аццкого iowait на dm-crypt'овых разделах.

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

>> Какую скорость dd в файл у тебя показывает?

Кстати, насчёт «в файл». Для интереса создал LV (VG на dm-crypt, разумеется) размером в 4Gb (физически это в конце диска). Запись нулей прямо в устройство тома была со скоростью ~17Mb/s, а вот когда создал ФС на нём (ext3), и сделал запись в файл, то средняя скорость вышла примерно в три раза выше, и загрузка ЦП была заметно выше. Линукс такой линукс...

Недавно тут была тема с похожими симптомами, но не на dm-crypt, а на dm-raid (пятый) — такое ощущение, что проблема общая.

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

Ага, всё оказалось очень просто. Достаточно указать bs=4M (размер экстента LVM по умолчанию), и скорость становится чуть выше, чем при записи в файл на ФС. Как-то сразу не подумал, что у такого устройства другая структура.

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

намертво из-за аццкого iowait

ха-ха, а у меня всё нормально. Хотя тебе проще обвинить меня в кривых руках или тормозах в голове чем искать настоящую причину проблем :)

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

> даже truecrypt'овые ntfs-разделы, работающие через fuse, бегают быстрее.

Что?! Ты где-то фундаментально косячишь: наличие шифрования замедляет ввод-вывод примерно на 20%, как тут уже говорили

annoynimous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.