>>> Ничего. Если пространства в свопе станет нехватать, сделаю файлом или вообще, swapd.
>>А как же "оптимизация", низкоуровневость и прочие карго-обжекты?
> Никак, естественно.Т.е. шизофрении категорически не замечаем?
> Какой боржоми, когда почки уже того?
Если для вас это критично - почему не предлагаете унести все с сервера,
переразбить диск и продолжить быть "оптимизированным"? Это все ведь
сейчас - относительно элементарные операции, без простоя сервисов и проч.
Может потому, что даже соображалка понимает бессмысленность этого
онанизма в большинстве ситуаций?
>>> 1) помогать работе механизма распределения памяти, если "ОЗУ достаточно и "своп не
>> нужен"
>>>Вот именно. Задача у него сейчас одна - не быть использованным.
> Читали код? А почитайте. Своп, если доступен, *всегда* используется при перераспределении памяти.
Да нет, конечно. У VM куча настроек, как и у любой подсистемы. Если памяти хватает,
то по-умолчаниям, принятым в большинстве дистрибутивов - систему нужно еще
_заставить_ пользовать своп (настройками). Чисто для примера: на одном вот сервере,
посмотрел, используется 93% памяти, своп - несколько килобайт. На другом - 95%, своп - 0.
>>> 2) предоставлять стабильное хранилище для сброса ОЗУ при приостановке работы системы
>>Ну и зачем тут копейки от выкидывания лишнего lvm-уровня? С поттерингом
>>меряться временем загрузки?
> Ой, вот *тут* время никого не волнует, разумеется.
Да вас же только что волновало: "В случаях 1- 2, быстродействие своп-подсистемы
критически важно." Сходите все-таки к доктору, так голову запускать не след.
>>> Нужно бы измерить, какие задержки вносит механизм LVM в общую механику распределения
>>> памяти, если раздел на LVM. Думаю, что вполне измеримые.
>>Нужно просто элементарно _знать_ как это работает. Эффект от пары лишних сисколлов,
>>конечно, измерим, но на уровне погрешности рулетки.
> Разбирались в коде лвм? Отлично. Расскажите, как это работает.
Тому, кто банально с головой не дружит? Дурных нема, это все-таки
выходит за рамки простого стеба.