Сочетание клавиш в режиме презентации Evince

Я думаю, что ваша догадка в самом конце вашего вопроса на верном пути. Я бы подозревал либо A, NUMA-aware распределение памяти, мигрирующее страницы между процессорами, либо B, что более вероятно, код дефрагментации прозрачных огромных страниц, пытающийся найти смежные, выровненные области.

Hugepages и прозрачные hugepages были идентифицированы как для заметного улучшения производительности на определенных рабочих нагрузках, так и ответственные за потребление огромного количества процессорного времени без предоставления значительной пользы.

Было бы полезно знать, на каком ядре вы работаете, содержимое /proc/meminfo (или хотя бы значения HugePages_*.), и, если возможно, больше коллграфа профилировщика vtune, ссылающегося на pageblock_pfn_to_page().

Также, если позволите, попробуйте отключить дефраг огромной страницы:

echo 'never' >/sys/kernel/mm/transparent_hugepage/defrag

(вместо этого может быть следующее, в зависимости от вашего ядра:)

echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/defrag

Наконец, это приложение, использующее многие десятки гигов оперативной памяти, написано вами? На каком языке?

Поскольку вы использовали термин "ошибки в страницах памяти", я предполагаю, что вы достаточно хорошо знакомы с операционной системой и виртуальной памятью. Я с трудом представляю себе ситуацию/приложение, которое бы так агрессивно ошибалось, но при этом не считывало бы большое количество ввода-вывода - почти всегда из буферного кэша, который вы пытаетесь ограничить.

(Если вам интересно, проверьте флаги mmap(2), такие как MAP_ANONYMOUS и MAP_POPULATE и mincore(2), которые можно использовать, чтобы увидеть, какие виртуальные страницы на самом деле имеют сопоставленную физическую страницу)

Удачи!