Что вызывает операции с памятью ядра в статистике производительности для процесса, предназначенного только для пользоват ⇐ C++

[Anonymous]

Я запускаю простую программу, в которой:

• Поток, прикрепленный к ЦП 1, выполняет случайное чтение из заранее выделенной и инициализированной области памяти размером 2 ГБ и во время цикла доступа к памяти не выполняется никаких системных вызовов.
• Perf работает в отдельном процессе, измеряющем mem_inst_retired.all_loads:k,mem_inst_retired.all_stores:k -I 200 -p

Вот минимальный тестовый код:

Код: Выделить всё

void access_memory(char *memory) {
// Pin thread to CPU 1
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(1, &cpuset);
pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);

std::mt19937 gen(std::random_device{}());
std::uniform_int_distribution dist(0, 2GB - 500);
char buffer[500];

while (!should_stop) {
size_t offset = dist(gen);
memcpy(buffer, memory + offset, 500);
buffer[0]++;
}
}

Вопросы:

• Почему выполняются какие-либо операции с памятью ядра, когда процесс выполняет только чтение памяти из пользовательского пространства? Хотя это может быть эффектом наблюдателя, могут ли прерывания, генерируемые PMU (блоком мониторинга производительности) для выборки, заставлять ядро ​​выполнять операции с памятью, которые приписываются процессу доступа? Я просмотрел SDM, но не нашел хорошего ответа.
• Как perf приписывает операции режима ядра конкретному процессу? Что касается системных вызовов, то ясно, что ядро ​​работает «от имени» процесса, но как насчет задач ядра, таких как планирование, сжатие памяти или балансировка нагрузки, которые могут повлиять на процесс? Где проходит черта?

Я заметил, что изменение интервала выборки с 200 мс на 5 с приводит к изменению измеряемых операций ядра с ~ 10^5 до ~ 10. ^7 операций за интервал.

Код: Выделить всё

sudo perf record -e mem_inst_retired.all_loads:k -p  -- sleep 20

#
# Samples: 15  of event 'mem_inst_retired.all_loads:k'
# Event count (approx.): 30000045
#
# Overhead  Command    Shared Object      Symbol
# ........  .........  .................  ..................................
#
13.33%  perf-ldst  [kernel.kallsyms]  [k] effective_cpu_util
13.33%  perf-ldst  [kernel.kallsyms]  [k] irq_work_run_list
6.67%  perf-ldst  [kernel.kallsyms]  [k] _raw_spin_lock
6.67%  perf-ldst  [kernel.kallsyms]  [k] _raw_spin_lock_irq
6.67%  perf-ldst  [kernel.kallsyms]  [k] decay_load
6.67%  perf-ldst  [kernel.kallsyms]  [k] irq_work_tick
6.67%  perf-ldst  [kernel.kallsyms]  [k] ktime_get_update_offsets_now
6.67%  perf-ldst  [kernel.kallsyms]  [k] native_apic_msr_eoi
6.67%  perf-ldst  [kernel.kallsyms]  [k] perf_adjust_freq_unthr_context
6.67%  perf-ldst  [kernel.kallsyms]  [k] rcu_sched_clock_irq
6.67%  perf-ldst  [kernel.kallsyms]  [k] sugov_update_single_freq
6.67%  perf-ldst  [kernel.kallsyms]  [k] update_curr
6.67%  perf-ldst  [kernel.kallsyms]  [k] update_load_avg

Непонятно, почему прерывания таймера/планировщика приписываются выполняющемуся процессу. Это задачи обслуживания системы, которые будут выполняться независимо от того, какой процесс запущен, а не выполняться «от имени» нашего процесса, как это было бы при системном вызове.
Вот простой код, который выполняет получает доступ и измеряет активность загрузки/сохранения:
https://gist.github.com/VinayBanakar/8c ... d3e3687aac

Подробнее здесь: https://stackoverflow.com/questions/791 ... ly-process