Как работает Load Store Queue при наличии MSHR?

Я понимаю базовую работу очереди загрузки-хранилища, которая

  1. когда загрузки вычисляют свой адрес, они проверяют очередь хранилища на наличие любых предыдущих хранилищ по тому же адресу, и если таковая имеется, они получают данные из самого последнего хранилища, а также из буфера записи или кеша данных.
  2. Когда магазины вычисляют свой адрес, они проверяют очередь загрузки на предмет нарушений загрузки.

Я сомневаюсь, что происходит, когда

  1. В первом случае, когда загрузка кэша данных доступа из-за некоторых неразрешенных адресов хранилища в очереди хранилища и доступ отсутствует в кэше данных L1, и до того, как данные могут быть извлечены из кеша, адрес хранилища разрешается. Теперь магазин проверяет очередь загрузки на наличие нарушений. Зависимая нагрузка уже обращалась к кешу данных ранее, но еще не получила значение из кеша из-за отсутствия длительной задержки. Публикует ли магазин нарушение загрузки или выполняет пересылку от магазина к загрузке и отменяет данные из кеша?

  2. Когда отсутствует доступ к загрузке в кэше данных l1, то загрузки помещаются в MSHR, чтобы не блокировать этап выполнения. Когда промах устраняется, запись MSHR для этой загрузки содержит информацию о регистре назначения и физическом адресе. Таким образом, значение может быть обновлено в физическом регистре, но как MSHR сообщает очереди загрузки, что значение доступно? когда это происходит на стадии конвейера? Потому что я где-то читал, что MSHR хранит физические адреса, а очередь загрузки-хранилища хранит виртуальные адреса. Итак, как MSHR взаимодействует с LSQ?

Я не нашел никаких ресурсов относительно этих сомнений.


queue cpu-architecture cpu-cache micro-architecture
person Nebula    schedule 22.01.2021    source источник
comment
2: процессоры Intel, например, воспроизводят мопы, ожидающие результата кэш-промаха, ожидая, что это будет попадание L2, затем попадание L3, а затем, по-видимому, продолжают воспроизводить их до тех пор, пока они в конечном итоге не преуспеют. (Если эти мопы самые старые для этого порта). Странные эффекты производительности от близлежащих зависимых хранилищ в цикле поиска указателя на IvyBridge. Добавление дополнительной нагрузки ускоряет его?. Также см. Верхнюю часть Об уязвимостях RIDL и воспроизведении нагрузок, но при этом обратите внимание на предупреждение о необходимости редактирования.   -  person Peter Cordes    schedule 24.01.2021
comment
@Peter, по крайней мере, в моих тестах на Skylake они, кажется, только предположительно отправляют в ожидании попадания L1 или L2, но не L3 или выше. Это имеет смысл, поскольку попадания в L3 не являются постоянной задержкой. Таким образом, вы обычно получаете 3 полных отправки на L3 или DRAM , если есть одна инструкция, напрямую зависящая от загрузки. Вы, конечно, могли бы получить больше, если бы было больше зависимых инструкций, и это становится особенно интересно, когда у вас есть цепочка зависимых нагрузок.   -  person BeeOnRope    schedule 24.01.2021
comment
@BeeOnRope: Возможно, я неправильно запомнил, но я думал, что мы (вы) увидели бы много дополнительных рассылок за то время, когда uop ожидает промаха кеша из ОЗУ. Вероятно, это было с тестом на отслеживание указателя, чтобы мы могли постоянно иметь в полете ровно одну загрузку с промахом кеша, адрес которой был готов. У IIRC-охоты за указателем L2-hit была одна дополнительная отправка, а у L3-hit было еще пара, и казалось, что у L3-miss было достаточно дополнительных, чтобы объяснить запуск отправки каждые 5 циклов после определенной точки. Или что-то вдоль этих линий.   -  person Peter Cordes    schedule 24.01.2021
comment
@BeeOnRope: Есть ли хорошие вопросы и ответы с обновленным описанием повтора uop? Похоже, я так и не успел обновить некоторые из своих ответов после того, как мы обнаружили, что это не разделенная загрузка или пропуск кэша, который воспроизводится с RS, это зависит от них, поэтому погоня за указателем ввела нас в заблуждение. Но я надеялся, что где-то за пределами комментариев есть точное описание. Может на твоей вики?   -  person Peter Cordes    schedule 24.01.2021
comment
@PeterCordes - да, именно вы можете увидеть много повторов за один промах (до ~ 10, IIRC), но это в случаях вложенных повторов, таких как погоня за указателем, или в случаях, когда многие мопы зависят от нагрузки. Я не припомню ни одной повторной отправки с течением времени для чистых пропусков нагрузки, как вы описываете. Хотя для других случаев со временем происходят повторяющиеся отправки, возможно, вы об этом думаете: в случае пересылки от магазина к загрузке вы можете увидеть много повторов магазина с течением времени, если это зависит от недостающей нагрузки, или что-то.   -  person BeeOnRope    schedule 25.01.2021
comment
Я не знаю хороших вопросов и ответов, существующие материалы, без сомнения, разбросаны довольно случайным образом по существующим вопросам и в чатах. Я действительно сделал глубокое погружение, пытаясь точно охарактеризовать поведение воспроизведения (например, сколько зависимых операций можно воспроизвести, как долго горизонт для воспроизведения, но поведение было сложным, поэтому я не писал ничего подробного об этом ).   -  person BeeOnRope    schedule 25.01.2021
comment
@BeeOnRope: Я предполагал, что мопы загрузки, ожидающие адреса, ничем не отличаются от других мопов, ожидающих данных, но вы говорите, что это так. Таким образом, только мопы загрузки агрессивно воспроизводят в ожидании попадания в L3 или результата DRAM, возможно, чтобы попытаться уменьшить задержку при поиске указателя на 1 цикл, а не просто ждать прибытия данных? Итак, если бы у вас был цикл отслеживания указателя с загрузкой и тремя добавочными регистрами, зависящими от загрузки с отслеживанием указателя, вы ожидали бы одного повторного воспроизведения каждого из добавлений на каждом шаге, но много повторений загрузки? Предполагая, что L3 промахивается.   -  person Peter Cordes    schedule 25.01.2021
comment
@PeterCordes - Я, наверное, не очень хорошо себя объясняю. Я не думаю, что операции зависимой загрузки отличаются от других операций в этом смысле. Я не думаю, что в зависимости от загрузки операторы повторяют несколько (кроме трех, подразумеваемых повторными попытками L1 и L2) раз в случае погони за указателем загрузки-загрузки, как и другие операции. Я только что упомянул погоню за точками, потому что это случай, когда (транзитивно) много операций ждут каждой загрузки, так что вы можете получить больше, чем стандартные 3-кратные повторы за один промах. Я не помню, происходит ли это на самом деле? Дай мне проверить.   -  person BeeOnRope    schedule 25.01.2021
comment
Да, тест отслеживания указателя имеет 1, 2 или 3 мопа до p23 для областей L1, L2 и L3 / DRAM соответственно. Нет никакого непрерывного воспроизведения и никакого дополнительного ответа, связанного с промахом L3 против попадания L3. Это из uarch-bench load-serial тестов и p23 счетчиков uop.   -  person BeeOnRope    schedule 25.01.2021
comment
Я написал, что до того, как закончились последние две строки для регионов размером 131 и 262 МБ. Они действительно приближаются к 4 мопам к p23, а не к 3. Тем не менее, меньшие тесты, такие как 64 МБ, явно выходят за рамки L3, но не показывают этого. Я не уверен, какой здесь эффект, может быть, это связано с обходом страниц? Обновление: я считаю, что это связано с обходом страниц, поскольку, если я отключу THP, вы увидите ~ 4 для всех размеров, которые не подходят для L3.   -  person BeeOnRope    schedule 25.01.2021
comment
@BeeOnRope: Хорошо, я, должно быть, вспомнил еще одну причину повторов, которые продолжают агрессивно воспроизводиться. Логично, что цепочки зависимых нагрузок не являются особенными: если у груза еще нет готового адреса, поэтому он все еще ожидает в RS, мопы, в свою очередь, зависящие от него, еще не должны пытаться выдать. При чистом поиске указателей одновременно выполняется только одна загрузка (успешно отправлена, но результат еще не получен).   -  person Peter Cordes    schedule 25.01.2021
comment
@PeterCordes - есть случай, подобный тому, который вы описываете, IIRC, он включает в себя магазины и хранилище для пересылки загрузки. Что-то вроде того, что вы видите 1 p23 uop (или это был p4, я не могу вспомнить) для каждого цикла, когда переадресация магазина задерживается (например, b / c данные не готовы).   -  person BeeOnRope    schedule 25.01.2021
comment
Вероятно, в приведенном выше случае лишнее воспроизведение вызвано промахом TLB.   -  person BeeOnRope    schedule 25.01.2021
comment
@BeeOnRope: Интересно. Я помню попытку отправки каждые 5 циклов или что-то в этом роде, но это могло быть основано на недоразумении.   -  person Peter Cordes    schedule 25.01.2021
comment
@BeeOnRope: Да, я собирался сказать то же самое; Вероятно, промах L1dTLB вызывает дополнительное воспроизведение зависимых мопов в ожидании попадания L2TLB. Сам обход страниц не выполняет свою загрузку через uops AFAIK (вместо этого обращается к L1d независимо) и имеет непредсказуемую задержку, поэтому промах L2TLB кажется менее вероятным источником повторов. И получение ровно 1 дополнительного повтора для ваших размеров теста имело бы смысл либо для попаданий L2TLB, либо для полных промахов L2TLB, которые вызывают прогулку.   -  person Peter Cordes    schedule 25.01.2021
comment
Я помню попытку отправки каждые 5 циклов или что-то в этом роде ... да, я тоже помню что-то в этом роде, но IIRC это включало как загрузки, так и хранилища, или, возможно, только загрузки, но буферы заполнения были заполнены (например, он периодически проверял наличие свободного буфера заполнения).   -  person BeeOnRope    schedule 25.01.2021

Ответы (1)


arrow_upward
2
arrow_downward

  1. Это спекулятивное исполнение, при котором загрузка обходится без старых хранилищ. Когда старое хранилище разрешено, мы можем выбросить нарушение загрузки. Если вероятность псевдонима адреса мала, то спекулятивное исполнение является прибыльным (большая пропускная способность) - обычно это верно для программ. Обнаружив нарушение загрузки, мы можем предпринять соответствующий шаг - (а) пересылка от хранилища к загрузке или (б) конвейер отката до разрешенного хранилища.

  2. То же, что и при обслуживании нагрузок с помощью попаданий в кеш (для попадания L1 может потребоваться 1-3 цикла). Например, на станции резервирования с CDB (общей шиной данных) результат будет передан всем аппаратным структурам, которые в нем нуждаются.

person instinct71    schedule 23.01.2021