Как я понимаю, память, отображаемая в/в, не делает определенные инструкции магазина специальными. Магазин 8B от movq mem, xmm такой же, как и у магазина от mov mem, r64.
Я думаю, что если у вас есть 64B для записи в MMIO, вы должны делать это с помощью любых инструкций, которые наиболее эффективно выполняются с его созданием, а затем очищают строку кэша. Генерация буфера 64B, а затем выполнение memcpy (или сделать это самостоятельно с четырьмя movdqa или двумя AVX vmovdqa) - это пустая трата времени, если вы не ожидаете, что ваш код, который генерирует 64B, будет медленным и, скорее всего, будет прерван частично, чем тетср. Прерывание таймера может появиться в любое время, в том числе во время memcpy, если вы находитесь в пространстве пользователя, где вы не можете отключить прерывания. Так как вы не можете гарантировать полную запись 64B, вероятность 99,99% полной записи в кешках равна 99,99999% вероятности. не будет иметь значения.
Streaming stores в область MMIO может избежать процессора, выполняющего чтение для владения после clflush из предыдущей записи. clwb isn't available yet, so the only option is clflush, which evicts the data from cache.
Невременные нагрузки/магазины так называются слабоупорядоченными. IDK, если это означает, что вам нужно больше ограждений, чтобы гарантировать заказ.
Один чехол для потоковой передачи/хранения - copying from uncacheable memory, like video RAM. Я не уверен в использовании их для MMIO. Я нашел this article about it, рассказывая о том, как читать из MMIO, просто не получая одинаковое кешированное значение.
Вы уверены, что ваша реализация 'memcpy()' еще не использует инструкции SSE? –
memcpy от стандартного glibc, поэтому я немного сомневаюсь, если использует инструкции SSE. –
как медленно медленно? с или без SSE, копируя данные в порядке нескольких циклов. – user3528438