LINUX.ORG.RU
Форум — Development  

proc file content refresh


0

0
Некая самописная программа любит читать из /proc/self/statm первое значение (total program size) для корректировки собственной логики (например, чтобы понять, можно ли держать данные в памяти, или лучше устроить файл на диске). Происходит это настолько часто, что накладные расходы на чтение из proc стали заметны.

Если /proc/self/statm не переоткрывать, а просто снова и снова читать из него, то данные не меняются, но все работает примерно в 20 раз быстрее ;(.

Вопросы.

1. Есть ли какой-нибудь хитрый способ ускорения работы с proc, позволяющий избавиться от постоянных open/close?

2. Можно ли узнавать total program size другим способом?

Код приводить бесполезно, потому что все уходит в систему внутри open.

anonymous
← условные переменные
Debian-Depot + APT = удаление пакетов →
Просто открывать пореже?
alexru ★★★★
()
Ответ на: комментарий от anonymous
> mmap?

А что делать с mmap? Все равно ведь файл придется переоткрывать, насколько я понимаю.

anonymous
()
Небольшое продолжение про open/close. Насколько я понимаю, ядерная функция read_func http://www.aoc.nrao.edu/~tjuerges/alma/Kernel/procfs-guide/ch03.html, отвечающая за некоторый конкретный файл в proc, вызывается тогда и только тогда, когда в userland делают open. Соответственно, избавиться от open нельзя в принципе и никакой mmap здесь не помощник.

Медлительность open для /proc/self/statm связана (1) с переключением в режим ядра, (2) с работой слоев, догадывающихся, что это procfs и передающих туда управление и (3) с собственно заполнением statm.

При этом у меня нет никаких шансов избавиться ни от одной из трех стадий.

Верно ли изложенное выше?

anonymous
()
Ответ на: комментарий от anonymous
> Небольшое продолжение про open/close. Насколько я понимаю, ядерная функция read_func http://www.aoc.nrao.edu/~tjuerges/alma/Kernel/procfs-guide/ch03.html, отвечающая за некоторый конкретный файл в proc, вызывается тогда и только тогда, когда в userland делают open.

Точно не знаю, но для /dev она вызывалась каждый раз при чтении. Другое дело, что всякие fread/fwrite вроде-бы что-то буфферизуют(читают большими порциями но реже и т.д.) и если файл мелкий то для него и одного read хватает.

Может у тебя оно где-то в userland кэшируется и не обновляется? Попробуй через read/write, еще может O_SYNC при открытии повлияет.

YesSSS ★★★
()
Ответ на: комментарий от YesSSS
От накладных расходов не избавишься.

Если невозможно увеличить период обращения, то я вижу один способ решения (по крайней мере, я так бы сделал). А именно, написать маааленький модуль ядра, обеспечивающий один ioctl - запрос этой самой инфы из соответствующей структуры(или переменной) kernel-space'а (в монолитных кернелах есть свои прелести;-)). Модуль при инициализации ищет нужные данные (типа kallsyms_lookup_name) и сохраняет указатель, а при ioctl'е делает copy_to_user из этого пойнтера. Расходы и здесь есть, но всё не такие "слоёные" как в вышеописанном случае.

Удачи.

farisey
()
Ответ на: комментарий от farisey
Ну и, сессно, добавить ioctl, который передаёт модулю pid=getpid() , заставляя его тем самым обновлять информацию, когда запускаешь прогу в другой раз.
farisey
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← условные переменные
Development
Debian-Depot + APT = удаление пакетов →