В Linux 5.7 будет доступно использование Swap через Samba
В код ядра Linux 5.7 добавлена экспериментальная поддержка использования Swap-файла через SMB3. Эта возможность может применяться в случаях загрузки с SMB3 или других сетевых источников.

https://git.kernel.org/pub/scm/linux/ker...3156d2ba6e
It's time to kick gum and chew ass. And i'm all out of ass.
Ответ
Кому это понадобилось? реально интересны use cases.
Ответ
Кто-нибудь может мне объяснить, зачем это в ядре?

Ядро Linux и так уже чрезмерно жирное. Осталось только графический интерфейс туда засунуть.

Почему нельзя в ядре сделать какие-нибудь минимальные интерфейсы и оставить на откуп юзерспейсному драйверу?

Меру нужно знать.
Правила форума
[Новичкам] Как правильно задавать вопросы, чтобы Вам помогли

«Буду бить аккуратно, но сильно!» © Лёлик, х/ф «Бриллиантовая рука»
Ответ
cetjs2 post_id=330 time=1586723899 user_id=62 Написал:Кому это понадобилось? реально интересны use cases.

Да даже если это понадобилось целой огромной корпорации с 100500 человекомашин, это не значит, что нужно пихать всё в ядро.
Правила форума
[Новичкам] Как правильно задавать вопросы, чтобы Вам помогли

«Буду бить аккуратно, но сильно!» © Лёлик, х/ф «Бриллиантовая рука»
Ответ
В данном случае фича вообще сомнительна. Своп на HDD доказал свою несостоятельность в современном мире. SAMBA же - сетевое подключение по гигабитной скорости в лучшем случае. Я вообще не понимаю, зачем по протоколу SMB3 загружаться - есть кошерный PXE. Но даже если - скорость такого свопа весьма печальна и он годится только для того, чтобы скинуть на диск реально не нужные данные. Ну так и нехрен ненужные данные вообще хранить в ОЗУ, раз уж на то пошло.
Ответ
Цитата: Я вообще не понимаю, зачем по протоколу SMB3 загружаться - есть кошерный PXE.

Поддерживаю.

Цитата: скинуть на диск реально не нужные данные. Ну так и нехрен ненужные данные вообще хранить в ОЗУ, раз уж на то пошло.

Ещё бы управление памятью в Linux нормальное завезли. OOM Killer — местная страшилка, он как бы есть, но его никто не видел (или софт его просто не слушает). Система может встать раком и *никогда* не отвиснуть, просто потому, что самый жручий процесс никто никогда не убьёт. И остаётся надеяться, что софт писал рукожопый обезьян, и оно упадёт само, когда не сможет отожрать кончившуюся память.

Пресекая возможные «всё на самом деле не так плохо»: не от хорошей жизни в Linux появляются все эти oomd и прочие юзерспейсные утилиты, которые действительно нужны за неимением рабочих альтернатив в ядре.

Как бы плохо я не отзывался о macOS, а управление памятью у них реализовано и огранизовано просто безупречно.
Правила форума
[Новичкам] Как правильно задавать вопросы, чтобы Вам помогли

«Буду бить аккуратно, но сильно!» © Лёлик, х/ф «Бриллиантовая рука»
Ответ
[mention]mord0d[/mention] , а как во фре с убийством жрущих процессов?
Ответ
cetjs2 post_id=363 time=1586778860 user_id=62 Написал:[mention]mord0d[/mention] , а как во фре с убийством жрущих процессов?

OOM Killer приходит и убивает какие-то (логику я не понял, а в код не смотрел) процессы.

Когда у меня во время компиляции портов кончилась RAM, были убиты Firefox (с аптаймом в ≈3 дня, но он не использовался около двух, потому практически полностью был вымещен в swap), dnscrypt-proxy (не жрущий практически ничего; я аж охренел, когда у меня DNS отвалился) и ещё что-то по мелочи.

То есть OOM Killer в FreeBSD *работает*, но приходит только тогда, когда всё совсем печально.
Правила форума
[Новичкам] Как правильно задавать вопросы, чтобы Вам помогли

«Буду бить аккуратно, но сильно!» © Лёлик, х/ф «Бриллиантовая рука»
Ответ