LINUX.ORG.RU

Слежение за изменениями страниц памяти

 , ,


0

3

Существует ли под онтопик аналог MEM_WRITE_WATCH из оффтопика — возможность для процесса узнать, что в страницу памяти была произведена запись? А то единственное юзерспейс-решение, похоже, это mprotect() и слушать SIGSEGV, но обработчик сигнала-то кто угодно может переопределить и пока слушалке.

Я так понял, прямая реализация того, что есть у Винды, нам не светит как минимум до 2020 года (US Patent 6738875). Но по идее можно прицепиться к обработчику #PF вместо вытеснения страниц на диск, обойдя ограничения патента. Не знаю, правда, насколько это будет тормозить.

Или правильные посоны следят за изменениями через шаманство с fork() и copy-on-write?

★★★

Забей на патент. SBCL (и, скорее всего, его предок CMUCL) так испокон веков делает.

mv ★★★★★
()

Чуть больше втыкания в код и доку показали, что слушание #PF, каким я его себе представлял, уже реализовано. Называется soft-dirty flag. Управление им не гранулярно, можно сбросить флажки только для всех страниц процесса сразу, но в общем-то это позволяет смотреть, какие страницы изменились.

ilammy ★★★
() автор топика
Ответ на: комментарий от Harald

Не, я думал, эту штуку используют все, кто пишет сборщики мусора с поколениями. Там же важно следить, когда в старом поколении появляются ссылки на молодые объекты. Вот и задумался, как это делается (кроме оборачивания транслятором каждой записи по указателю в if). Уж вряд ли это делается через дебаггер и брейкпоинты, если следить надо за всей памятью сразу.

ilammy ★★★
() автор топика
Ответ на: комментарий от mv

Только если ты сборщик мусора пишешь, то так делать не надо: изменение атрибутов у одной страницы дробит vma на 2-3, и в итоге получается по vma на страницу. Это жутко тормозно и добавляет много оверхеда по памяти. Если увеличивать размер «страницы» с точки зрения сборщика, то ему нужно больше памяти сканировать, что приводит к ещё большим тормозам, чем в обычном сборщике.

mv ★★★★★
()
Ответ на: комментарий от mv

Атрибут же по идее надо сбрасывать у всех страниц региона виртуальной памяти, где лежит старое поколение, так что VMA не должны (особо) дробиться: только с краёв региона что-то отделять может понадобиться.

ilammy ★★★
() автор топика
Ответ на: комментарий от ilammy

Write protection выступает в роли флага «грязной» памяти, которую сборщик должен просканировать. SBCL после сборки мусора сбрасывает wp для всех страниц. Первое обращение на запись в страницу вызывает сегфолт, он это ловит и разрешает запись. Это необратимо крошит VMA.

mv ★★★★★
()
Ответ на: комментарий от mv

Ой, да. Точно. Про то, что он сбрасывется назад, я забыл, лол.

Вот теперь тот подход со слежением за dirty-флагом, который MMU ставит без специальных приглашений, кажется ещё более подходящим.

ilammy ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.