Подсчет количества выделений в очереди ожидания записи - неожиданный низкий результат в памяти NV

Я пытаюсь использовать некоторые аппаратные счетчики uncore, например: skx_unc_imc0-5::UNC_M_WPQ_INSERTS. Предполагается, что он подсчитывает количество выделений в очереди ожидания записи. Машина имеет 2 процессора Intel Xeon Gold 5218 с архитектурой каскадного озера, с 2 контроллерами памяти на процессор. версия linux - 5.4.0-3-amd64. У меня есть следующий простой цикл, и я читаю для него этот счетчик. Элементы массива имеют размер 64 байта, равный строке кеша.

for(int i=0; i < 1000000; i++){
        array[i].value=2;
}

Для этого цикла, когда я сопоставляю память с узлом DRAM NUMA, счетчик в результате дает около 150 000, что, возможно, имеет смысл: всего 6 каналов для 2 контроллеров памяти перед этим узлом NUMA , которые используют модули DRAM DIMM в режиме чередования. Тогда для каждого канала есть один отдельный WPQ, я полагаю, поэтому skx_unc_imc0 получает 1/6 от всех магазинов. Есть skx_unc_imc0-5 счетчики, которые я получил с papi_native_avail, предположительно каждый для разных каналов.

Неожиданный результат заключается в том, что вместо сопоставления с узлом DRAM NUMA я сопоставляю программу с энергонезависимой памятью, которая представлена ​​как отдельный узел NUMA с тем же сокетом. На каждый сокет приходится 6 модулей памяти NVM DIMM, которые создают одну чередующуюся область. Таким образом, при записи в NVM должно быть аналогично 6 разных каналов, и перед каждым стоит один и тот же WPQ, который снова должен иметь 1/6 вставок записи.

Но UNC_M_WPQ_INSERTS возвращает только около 1000 из-за энергонезависимой памяти. Я не понимаю почему; Я ожидал, что он даст примерно 150 000 записей в WPQ.

Я что-то неправильно интерпретирую / понимаю? Или есть два разных WPQ на канал в зависимости от того, идет ли запись в DRAM или NVM? Или чем еще может быть объяснение?


person Ana Khorguani    schedule 23.03.2020    source источник
comment
Моя единственная гипотеза: 1) Этот счетчик учитывается только для DRAM (каким-то образом записи в NVDIMM обрабатываются по-разному), 2) записи не попадают в MC, либо потому, что они останавливаются раньше (как так?), Либо потому что есть внутренний, отдельный, контроллер NVDIMM в самом МК. 3) модули NVDIMM находятся за (возможно, интегрированным) контроллером PCIe (который является реальной целью записи вместо MC). Но я не понимаю, как этот список поможет вам: D Я имею в виду, что эти записи не могут просто исчезнуть!   -  person Margaret Bloom    schedule 24.03.2020
comment
@MargaretBloom Я согласен, им нужно куда-то идти. Я начинаю думать, что это каким-то образом счетчик, возможно, только отслеживает записи в DRAM, хотя мне не имеет никакого смысла, почему он это делает. Вот этот документ: arxiv.org/pdf/1908.03583.pdf, в котором описаны некоторые детали архитектура, в разделе 2.1.1. Они говорят, что iMC поддерживает очереди ожидания чтения и записи (RPQ и WPQ) для каждого из модулей DIMM 3D XPoint, поэтому я был бы менее удивлен, если бы вместо DRAM учитывались только записи NVM.   -  person Ana Khorguani    schedule 24.03.2020
comment
Вы пробовали контролировать все счетчики со всех iMC? Может ли быть так, что записи направляются на другой iMC, чем ожидалось?   -  person Margaret Bloom    schedule 24.03.2020
comment
Я перепробовал все 6 из skx_unc_imc0-5, но для NVM нет ничего. Для DRAM каждый получает 1/6.   -  person Ana Khorguani    schedule 24.03.2020
comment
@MargaretBloom Оказывается, ваша первая гипотеза верна. Я нашел здесь: download.01.org/perfmon/index/cascadelake_server.html что есть еще один счетчик UNC_M_PMM_WPQ_INSERTS, который подсчитывает запросы на запись, выделенные в очереди ожидания записи PMM для постоянной памяти Intel® Optane ™ DC. Но, к сожалению, papi_native_avail не показывает мне это событие ни на одной из машин каскадных озер, к которым у меня есть доступ, поэтому я даже не проверял его раньше :(   -  person Ana Khorguani    schedule 24.03.2020
comment
Есть ли способ, что этот аппаратный счетчик UNC_M_PMM_WPQ_INSERTS может быть доступен на машине, но не отображаться в papi_native_avail? а использовали как-то еще?   -  person Ana Khorguani    schedule 24.03.2020
comment
Глядя в исходный код, кажется, что PAPI не знает об этом событии. Может быть, вы можете попробовать отправить им электронное письмо, или мы можем попытаться взломать это событие в исходный код: D   -  person Margaret Bloom    schedule 25.03.2020
comment
Идея мне нравится: D Я отправлю им электронное письмо. Взлом их исходного кода тоже кажется забавным. Однако я подумал, что, может быть, есть способ проверить, поддерживается ли событие самой машиной? Несмотря на то, что на странице Intel есть это новое событие, оно может быть интегрировано не во все машины с каскадными озерами?   -  person Ana Khorguani    schedule 25.03.2020
comment
Я думаю, что это есть во всех CascadeLakes. Однако мне не удалось найти никакой официальной документации. Документация uncore PMU, похоже, отсутствует. Linux perf хотя и поддерживает эти новые события, так что, может быть, ты сможешь проверить это? Я думаю, что в PAPI их не хватает, потому что они могут не соответствовать Intel.   -  person Margaret Bloom    schedule 25.03.2020
comment
Я проверяю производительность прямо сейчас. До сих пор я обнаружил следующее с perf list uncore: unc_m_pmm_bandwidth.write - [Запись пропускной способности постоянной памяти Intel Optane DC (МБ / с). Получено из unc_m_pmm_wpq_inserts. Unit: uncore_imc], что означает, что где-то там должен быть unc_m_pmm_wpq_inserts: D   -  person Ana Khorguani    schedule 25.03.2020
comment
На данный момент perf stat -e unc_m_pmm_bandwidth.write возвращает результат, но когда я пытаюсь напрямую perf stat -e unc_m_pmm_wpq_inserts, я получаю ошибку парсера.   -  person Ana Khorguani    schedule 25.03.2020
comment
perf поддерживает необработанные события, поэтому, согласно this, команда perf stat -e uncore_imc/event=0xe7 должна подсчитывать вставки WPQ для PMM. Вы сможете получить больше информации о необработанном формате, используемом perf (в частности, о имени PMU) с помощью команды ls /sys/devices/*/format. Я не уверен, как это все работает на машине NUMA: /   -  person Margaret Bloom    schedule 25.03.2020
comment
Ничего себе, большое спасибо, что-то начало работать: D Я использовал perf stat -e uncore_imc/event=0xe7/ вот так, и он возвращает какое-то значение. Для начала я пытаюсь понять, как добавить МОДИФИКАТОРЫ СОБЫТИЙ в этот необработанный формат, чтобы получить только подсчет пространства пользователя. с именем было бы просто добавить: u вот так: perf stat -e unc_m_pmm_wpq_inserts:u, но кажется, что с сырой версией все не так просто.   -  person Ana Khorguani    schedule 25.03.2020
comment
В конце должно быть что-то вроде /u. Но как вы думаете, ядро ​​пишет в NVRAM?   -  person Margaret Bloom    schedule 25.03.2020
comment
Хорошо, я попытался добавить perf stat -e uncore_imc/event=0xe7/u, он возвращает что-то вроде ‹not supported›, что, я думаю, означает, что само событие не поддерживает этот идентификатор события.   -  person Ana Khorguani    schedule 25.03.2020
comment
Позвольте нам продолжить это обсуждение в чате.   -  person Margaret Bloom    schedule 25.03.2020
comment
Могут быть недокументированные события для полных циклов PMM WPQ и не пустых циклов PMM WPQ. Вы проверяете, имеют ли события IMC 0xE5, 0xE6, 0xE8 и 0xE9 счетчики больше нуля. Попробуйте также различные варианты вашей программы, например, большие размеры элементов массива (128 байтов, 256 байтов и 512 байтов) и разверните цикл несколько раз. В качестве альтернативы эти события можно аппроксимировать с помощью UNC_M_PMM_WPQ_OCCUPANCY.ALL / UNC_M_CLOCKTICKS и, возможно, модификатора cmask=1. Обратите внимание, что модификатор u не может использоваться с событиями uncore.   -  person Hadi Brais    schedule 19.04.2020
comment
@HadiBrais Привет, большое спасибо за предложения. Я применю их все до конца недели и тоже прокомментирую результаты.   -  person Ana Khorguani    schedule 21.04.2020
comment
@HadiBrais привет, извините за такой поздний ответ. Я тестировал сейчас, 0xE5 насчитывает 68 303 263 для цикла выше 1 миллиона записей. Остальные счетчики возвращают 0. Я попытался добавить еще несколько циклов записи, но это не изменило ничего, кроме результата 0xE5, пропорционально. То же самое для размеров элементов. Но что это за счетчики? Мне не удалось их найти здесь   -  person Ana Khorguani    schedule 24.04.2020
comment
Я могу сосчитать UNC_M_CLOCKTICKS с именем. Для UNC_M_PMM_WPQ_OCCUPANCY.ALL я использовал 0xE4, хотя он возвращает 0. Добавление cmask следующим образом: uncore_imc/event=0xe4,cmask=0x1/ дает синтаксическую ошибку события.   -  person Ana Khorguani    schedule 24.04.2020
comment
Отлично. События 0xE5, 0xE6, 0xE8 и 0xE9 недокументированы. Можете ли вы попробовать использовать цикл чтения вместо цикла записи? Событие UNC_M_PMM_WPQ_OCCUPANCY.ALL требует umask=0x1. Вы можете использовать его только по имени в ядре v5.5-rc1 и новее. Какое значение имеет UNC_M_CLOCKTICKS?   -  person Hadi Brais    schedule 24.04.2020
comment
А, хорошо, понятно. Счетчик UNC_M_CLOCKTICKS равен 450 584 412 для этого цикла записи. Для UNC_M_PMM_WPQ_OCCUPANCY.ALL uncore_imc/event=0xe4,umask=0x1/ возвращает значение: 959,793,105. Я добавил цикл чтения после записи, и счетчики 0xE6, 0xE8 и 0xE9 по-прежнему равны 0. Результат 0xE5 такой же.   -  person Ana Khorguani    schedule 24.04.2020
comment
@HadiBrais Для оценки UNC_M_PMM_WPQ_OCCUPANCY.ALL / UNC_M_CLOCKTICKS на основе результатов, кажется, около 2. Я не уверен, что это так, как ожидалось, или нет. Также я думаю, что через некоторое время я попробую поиграть с версией ядра, обновить ее и посмотреть, получу ли я что-нибудь еще с новой версией.   -  person Ana Khorguani    schedule 02.05.2020
comment
Что ж, соотношение 2 означает, что средняя загрузка WPQ составляет всего 2, что намного меньше, чем я ожидал. Попробуйте использовать большее количество итераций, например 10 миллионов или 1 миллиард. Попробуйте также измерить uncore_imc/event=0xe4,umask=0x1,cmask=0x1/ и посмотреть, как он сравнивается с cmask = 0x0.   -  person Hadi Brais    schedule 02.05.2020
comment
@HadiBrais К сожалению, это: uncore_imc/event=0xe4,umask=0x1,cmask=0x1/, похоже, не работает, я получаю синтаксическую ошибку события. Для UNC_M_PMM_WPQ_OCCUPANCY.ALL / UNC_M_CLOCKTICKS с 10 миллионами записей соотношение увеличивается до 3. Это также 3 со 100 миллионами записей. с 1 миллиардом это снова 2.   -  person Ana Khorguani    schedule 02.05.2020
comment
Я попытался добавить инструкцию сброса и забор памяти после операции записи внутри цикла. для 1 миллиона записей я получаю 108 109 453 uncore_imc/event=0xe4,umask=0x1/ и 2 164 543 760 для UNC_M_CLOCKTICKS. Без ограничения памяти просто clwb дает 514 017 990 UNC_M_CLOCKTICKS и 218 640 321 uncore_imc/event=0xe4,umask=0x1/. Я ожидал, что UNC_M_PMM_WPQ_OCCUPANCY.ALL увеличится, так как я сбрасываю записи, которые должны насытить этот WPQ больше, но это не выглядит так.   -  person Ana Khorguani    schedule 02.05.2020
comment
@MargaretBloom Я как раз читал этот ответ: stackoverflow.com/a/50322404/12419816. Здесь автор, кажется, заявляет, что mfence - это инструкция, которая гарантированно очищает буфер хранилища. sfence тоже делает это?   -  person Suraaj K S    schedule 12.11.2020
comment
@SuraajKS В руководстве Intel говорится, что тесты, выполненные другими пользователями, говорят, что нет. Я задал ваш точный вопрос в комментариях (самых последних) к ответу, который вы связали. Я никогда не тестировал это лично.   -  person Margaret Bloom    schedule 12.11.2020
comment
@AnaKhorguani Если вы все еще ищете события, которые представляют полные циклы PMM WPQ и PMM WPQ не пустые циклы, мои предыдущие предложения по использованию событий 0xE6 и 0xE5 верны в соответствии с https://download.01.org/perfmon/CLX/cascadelakex_uncore_v1.11_experimental.json. Они называются UNC_M_PMM_WPQ_CYCLES_FULL и UNC_M_PMM_WPQ_CYCLES_NE соответственно.   -  person Hadi Brais    schedule 11.03.2021
comment
@HadiBrais Привет, спасибо за документ. Я вернулся к проверке этих счетчиков. Это немного интригует, поскольку мне не удалось заставить 0xE6 считать что-то, кроме 0 для любой программы: D, что означает, что очередь отложенной записи не заполняется. 0xE5 ближе к ожидаемому поведению (значительно уменьшается или достигает 0 при привязке памяти к DRAM и достигает миллиардов, когда память привязана к NVM)   -  person Ana Khorguani    schedule 26.05.2021
comment
Да, думаю, не наполняется. В настоящее время у меня нет доступа к системе с pmem для тестирования некоторых микробенчмарков, которые, как я думаю, позволили бы заполнить ее, но это интересная и важная проблема анализа микроархитектуры.   -  person Hadi Brais    schedule 29.05.2021
comment
@HadiBrais Я согласен. Если это действительно показывает, что очередь ожидания записи не заполняется, это означает, что контроллер памяти для NVM не становится узким местом. Если эти микробенчмарки доступны и просты в использовании, я мог бы их протестировать.   -  person Ana Khorguani    schedule 02.06.2021


Ответы (1)


Оказывается, UNC_M_WPQ_INSERTS подсчитывает количество выделений в очереди ожидания записи только для записи в DRAM. Intel добавила соответствующий аппаратный счетчик для постоянной памяти: UNC_M_PMM_WPQ_INSERTS, который подсчитывает количество запросов на запись, выделенных в очереди ожидания записи PMM для постоянной памяти Intel® Optane ™ DC.

Однако в papi_native_avail нет такого собственного события, что означает, что его пока нельзя отслеживать с помощью PAPI. В Linux версии 5.4 некоторые счетчики PMM можно найти непосредственно в perf list uncore, например unc_m_pmm_bandwidth.write - Запись пропускной способности постоянной памяти Intel Optane DC (МБ / с), полученная из unc_m_pmm_wpq_inserts, unit: uncore_imc. Это означает, что даже если UNC_M_PMM_WPQ_INSERTS не указан прямо в perf list как событие, оно должно существовать на машине.

Как описано здесь, EventCode для этого счетчика: 0xE7, поэтому его можно использовать с perf в качестве необработанного дескриптора аппаратного события следующим образом: perf stat -e uncore_imc/event=0xe7/. Однако похоже, что он не поддерживает модификаторы событий для указания подсчета пространства пользователя с помощью perf. Затем, после закрепления потока в том же сокете, что и узел NVM NUMA, для программы, которая в основном выполняет только цикл, описанный в вопросе, результат perf имеет смысл:

Performance counter stats for 'system wide':  1,035,380    uncore_imc/event=0xe7/

Пока это кажется лучшим предположением.

person Ana Khorguani    schedule 25.03.2020