Почему 16 степпингов по 4K в основной памяти не вызывают пропадания кэша L1d

Question

Я нахожусь на IvyBridge и хочу проверить организацию кэша L1d. Мое понимание таково:

В IvyBridge кэш L1d имеет емкость 32 КБ, строку кэша 64 Б, ассоциативно настроенный 8-канальный. Поэтому он имеет 32K / (64 * 8) = 64 набора, учитывая основную память addr, индекс набора может быть вычислен как (addr/64) % 64.

Так что, если я увеличу основную память на 64 * 64 (4K), я всегда буду касаться одного и того же набора L1d. В наборе всего 8 строк кэша, поэтому, если зациклить его на 16 шагов, я получу почти 100% пропуск кэша L1d.

Я пишу следующую программу для проверки:

section .bss
align   4096
buf:    resb    1<<26

%define gap 64 * 64 ; no L1 cache miss

; %define gap 64 * 64 * 256 ; 41% L1 cache miss

; %define gap 64 * 64 * 512 ; 95% L1 cache miss
; however, total cycle suggests this gap is already at L3 latency level with complete L2 cache miss.

section .text
global _start
_start:
    mov rcx,    10000000
    xor rax,    rax
loop:
    mov rax,    [buf+rax]
    mov rax,    [buf+rax+gap*1]
    mov rax,    [buf+rax+gap*2]
    mov rax,    [buf+rax+gap*3]
    mov rax,    [buf+rax+gap*4]
    mov rax,    [buf+rax+gap*5]
    mov rax,    [buf+rax+gap*6]
    mov rax,    [buf+rax+gap*7]

    mov rax,    [buf+rax+gap*8]
    mov rax,    [buf+rax+gap*9]
    mov rax,    [buf+rax+gap*10]
    mov rax,    [buf+rax+gap*11]
    mov rax,    [buf+rax+gap*12]
    mov rax,    [buf+rax+gap*13]
    mov rax,    [buf+rax+gap*14]
    mov rax,    [buf+rax+gap*15]

    dec rcx,
    jne loop

    xor rdi,    rdi
    mov rax,    60
    syscall

К моему удивлению, perf показывает, что кэш-память L1 отсутствует вообще:

  160,494,057      L1-dcache-loads
        4,290      L1-dcache-load-misses     #    0.00% of all L1-dcache hits

Что не так в моем понимании?

Answer 1

Все страницы BSS изначально сопоставляются копированием при записи на одну и ту же физическую нулевую страницу. Вы получите пропуски TLB (и, возможно, программные ошибки страницы), но пропуски L1d не будут.

Чтобы избежать этого и отобразить их на разных физических страницах:

• сначала запачкайте их, записав байт на каждую страницу
• возможно выделите с mmap(MAP_POPULATE) вместо использования BSS. Это, по крайней мере, предварительно нарушило бы их, избегая сбоев программных страниц, но, возможно, все еще на той же физической нулевой странице.
• поместите buf в раздел .data или .rodata, где он будет фактически отображен с файловой поддержкой. (Вам придется сделать его намного меньше, потому что нули на самом деле будут в исполняемом файле).

Более интересный (для меня) результат состоит в том, что вы делаете начинаете получать ошибки кеша с большим шагом . Тогда вы получаете доступ к большему количеству страниц 4k, и это может привести к тому, что ваше ядро ​​начнет использовать огромную страницу 2M для вашего BSS, иронически повреждая ее, сделав их уже не псевдонимом для той же физической страницы 4k. Вы можете проверить /proc/PID/smaps, чтобы увидеть, есть ли ненулевое AnonHuge для этого отображения.

---

Ожидаются пропуски L2, потому что это только 8-позиционная ассоциация, но L3 более ассоциативна и использует непростую функцию индексации, которая распределяет любую простую степень 2 шага по нескольким наборам. ( Какой метод отображения кэша используется в процессоре Intel Core i7? )

Кстати, вам может потребоваться разрыв, не равный степени 2. Всего лишь кратность шага алиасинга L1, но не шага алиасинга L2, поэтому ваши данные могут распределяться по множеству наборов в L2.

Я искал дубликаты, но не нашел точного, хотя я почти уверен, что уже объяснял это где-то на SO>. <. Вероятно, я думаю о <a href="https://stackoverflow.com/questions/48981887/how-can-i-obtain-consistently-high-throughput-in-this-loop"> Как я могу получить стабильно высокую пропускную способность в этом цикле? , где именно эта проблема была с malloc, а не с BSS.

Связанный:

• Правда ли, что современная ОС может пропускать копирование при вызове realloc имеет некоторые полезные сведения о виртуальной памяти / COW с нулевыми страницами для mremap.
• Создает ли malloc ленивые страницы резервирования для размещения в Linux (и на других платформах)? (ленивое выделение / даже не настройка таблицы страниц изначально отдельно от сопоставления COW с нулевой страницей. всегда может выделить реальную страницу даже при доступе только для чтения при первом прикосновении к странице.)
• Как именно копирование при записи работает