>>> Ничего. Если пространства в свопе станет нехватать, сделаю файлом или вообще, swapd.
>>А как же "оптимизация", низкоуровневость и прочие карго-обжекты?
> Никак, естественно.

Т.е. шизофрении категорически не замечаем?

> Какой боржоми, когда почки уже того?

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

>>> 1) помогать работе механизма распределения памяти, если "ОЗУ достаточно и "своп не
>> нужен"
>>>Вот именно.  Задача у него сейчас одна - не быть использованным.
> Читали код? А почитайте. Своп, если доступен, *всегда* используется при перераспределении  памяти.

Да нет, конечно.  У VM куча настроек, как и у любой подсистемы.  Если памяти хватает,
то по-умолчаниям, принятым в большинстве дистрибутивов - систему нужно еще
_заставить_ пользовать своп (настройками).  Чисто для примера: на одном вот сервере,
посмотрел, используется 93% памяти, своп - несколько килобайт.  На другом - 95%, своп - 0.

>>> 2) предоставлять стабильное хранилище для сброса ОЗУ при приостановке работы системы
>>Ну и зачем тут копейки от выкидывания лишнего lvm-уровня?  С поттерингом
>>меряться временем загрузки?
> Ой, вот *тут* время никого не волнует, разумеется.

Да вас же только что волновало: "В случаях 1- 2, быстродействие своп-подсистемы
критически важно."  Сходите все-таки к доктору, так голову запускать не след.

>>> Нужно бы измерить, какие задержки вносит механизм LVM в общую механику распределения
>>> памяти, если раздел на LVM. Думаю, что вполне измеримые.
>>Нужно просто элементарно _знать_ как это работает.  Эффект от пары лишних сисколлов,
>>конечно, измерим, но на уровне погрешности рулетки.
> Разбирались в коде лвм? Отлично. Расскажите, как это работает.

Тому, кто банально с головой не дружит?  Дурных нема, это все-таки
выходит за рамки простого стеба.