Управление освобождением памяти в Android. Использование swap'а и прочее?

Question

[IDOL1234]

Ситуация:
есть телефон с 850 мб оперативной памяти, из которых после обновления до Android 4.3 мне доступно ~350 мб.
Когда я открываю, например, 3 страницы хабра в firefox'е, закрываются все прочие приложения, включая аську и плеер, что не слишком приятно.
Я хочу заставить андроид сохранять данные, не помещающиеся в оперативной памяти, в swap-файл на флешке. Я знаю, что это связано с тормозами и "убийством флэши", как любят писать на форумах, но, на мой взгляд, постоянная потеря данных (именно так я рассматриваю закрытие браузера со вкладками, загруженными до входа в метро, где нет связи) гораздо хуже этого. Повторю специально для тех, кто сейчас будет меня отговаривать: меня совершенно не устраивает текущая ситуация, я уже потратил кучу времени, я пойду до конца.

Что сделано:
Установлен Cyanogenmod 10.2, сделан полный бэкап. Скачаны исходники, собрано работающее (хе-хе) ядро с поддержкой свопа. Создан файл на 1 гб (чтобы 2 раза не бегать:) на съёмной SD карте. Обнаружен странный баг: mkswap, запущенный из эмулятора терминала, всегда задаёт размер области не более 1020 байт. Через ADB всё работает нормально. Типичная ситуация при активации:


Запускаем наглую рыжую морду:


Запускаем прожорливую игрушку:


Закрываем её и видим, что Firefox был закрыт.

Что я делаю не так?
В каком примерно месте исходников я могу найти механизм, управляющий распределением памяти, если это не ошибка конфигурации?
Есть ли какие-то глобальные ограничения на объём виртуальной памяти, которые я мог пропустить, собирая цианоген?

Answer 1

[Юрий Ярош]

Файл подкачки часто отключается в ядре при сборке... но это не ваш случай.
Вам нужно настроить параметры своппинга - там висят скрипты которые выставляют vfs_cache_pressure и vm_swappiness параметры ядра.
Вручную их можно выставить через sysctl и в файле /etc/sysctl.conf.
Есть ещё такое

Comments

[IDOL1234]

Хм, насколько я понял, vm_swapiness устанавливает только агрессивность использования свопа, но не его размер. Текущее значение - 60.
Ни одно приложение из маркета не работает, проверено. В лучшем случае, отправляют телефон в ребут, но обычно зависают.

[IDOL1234]

vfs_cache_pressure = 10. Хм.

[Юрий Ярош]

Собственно вы не можете явно контролировать объём памяти который используется для подкачки в данный момент времени, это решает SLAB аллокатор. Есть только эти два параметра... И я не уверен что их можно безопасно менять в процессе работы устройства.

[IDOL1234]

Согласен, после изменения параметров телефон часто уходит в ребут.
Опять же, согласен, я не могу напрямую влиять на это. Но я вижу, что завершение приложений начинается задолго до заполнения всей доступной виртуальной памяти. О чём это может говорить?

Answer 2

[Boleg2]

Как раз к слову - с утра листал в свежем номере Хакера статью на тему правки встроенного в Android механизма организации оперативной памяти. Может оно поможет? :)

Answer 3

[mik_os]

Смотреть вот на эту строчку и вот на эту функцию. По умолчанию (24*2/3 = 16) система разрешает 24-16=8 бекграундных процессов, и как только лимит исчерпан бекграундые процессы будут "кешироваться" и убиватся. А своп при таком объеме памяти бессмысленный. То что выводит команда free никак не относится к истинному положению дел в андроиде, система выделаяет себе почти всю память, и управляет ею сама (отдает приложениям при старте).