Как я понимаю, shared libraries не обязательно должны быть загружены в памяти всё время. Динамический линкер или кто там за них отвечает, может выкинуть любую разделяемую библиотеку из памяти, даже если работают какие-то приложения, которые слинкованы с ней. В момент вызова какой-то функции из этой shared libraries линкер как-нибудь разберётся, что делать. Если shared library не в памяти, мы видим офигевание HDD.
Я так понимаю, shared libraries выкидываются из памяти растущим кешем файловой системы, который занимает всю не выделенную никем RAM. Какая там политика размещения файлов я не знаю, но по наблюдениям:
1. на каком-то из рабочих столов висел ktorrent, чё-то качал. Это такое приложение, которое слинковано более чем с 9000 библиотек, ибо оно толстое-КДЕ-шное. Ну вот, висит себе и работает. Переключаемся между рабочими столами, всё ништяк.
2. Начинаем распаковывать где-нибудь 4-гиговый архив. Распаковываемое, видимо, ложится в кеш, а некоторые гуёвые shared libraries, которые использовались Ktorrent из памяти выкидываются, да и ktorrent из них ничего не вызывает, ибо не нужно ничего рисовать, когда тебя не видно.
3. Переключаемся на рабочий стол, где запущен ktorrent. HDD начинает охреневать, ktorrent тужится себя нарисовать. Чё-то считывает с диска, и рожает свой GUI. В общем, я думаю, это охреневание - есть считывание динамическим линкером файлов .so, которые были вытеснены тем шлаком, который я распаковываю.
Вопрос такой: можно ли некоторым приложениям выделять лимит на использование этого кеша? То есть, чтобы распаковываемый архив с музоном не простирался на всю памяти, вытесняя реально нужные штуки?
Ответ на:
комментарий
от mriadus
Ответ на:
комментарий
от mriadus
Ответ на:
комментарий
от KRoN73
Ответ на:
комментарий
от mriadus
Ответ на:
комментарий
от r0mik
Ответ на:
комментарий
от KRoN73
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.