Это большая проблема, которая включает в себя эффективность сетевого стека, но я буду придерживаться вашего конкретного вопроса инструкции. То, что вы предлагаете, - это асинхронная неблокирующая инструкция копирования, а не синхронная блокировка memcpy, доступная сейчас с использованием «rep mov».
Некоторые архитектурные и практические проблемы:
1) Неблокирующая memcpy должна потреблять некоторый физический ресурс, такой как механизм копирования, с временем жизни, потенциально отличающимся от соответствующего процесса операционной системы. Это довольно неприятно для ОС. Предположим, что поток A запускает memcpy непосредственно перед переключением контекста на поток B. Поток B также хочет сделать memcpy и имеет гораздо более высокий приоритет, чем A. Должен ли он ждать завершения работы memcpy потока A? Что если memcpy А был длиной 1000 ГБ? Предоставление большего количества механизмов копирования в ядре откладывает, но не решает проблему. По сути это нарушает традиционный цикл квантования времени и планирования ОС.
2) Для того чтобы быть общим, как и большинство инструкций, любой код может в любой момент выдать инструкцию memcpy, не обращая внимания на то, что делали или будут делать другие процессы. Ядро должно иметь некоторое ограничение на количество асинхронных операций memcpy в полете в любой момент времени, поэтому, когда наступает следующий процесс, его memcpy может быть в конце сколь угодно длинного отставания. В асинхронной копии отсутствует какой-либо детерминизм, и разработчики просто вернутся к старомодной синхронной копии.
3) Локальность кэша влияет на производительность первого порядка. Традиционная копия буфера, уже находящаяся в кэше L1, невероятно быстра и относительно энергоэффективна, поскольку, по крайней мере, целевой буфер остается локальным для ядра L1. В случае сетевого копирования, копирование из ядра в пользовательский буфер происходит непосредственно перед передачей пользовательского буфера в приложение. Таким образом, приложение имеет хиты L1 и отличную эффективность. Если асинхронный механизм memcpy существует не в ядре, а в операции копирования, он извлекает (отслеживает) строки из ядра, что приводит к отсутствию кэша приложения. Чистая эффективность системы, вероятно, будет намного хуже, чем сегодня.
4) Инструкция asynch memcpy должна возвращать какой-то токен, который идентифицирует копию для последующего использования, чтобы спросить, выполняется ли копия (требующая другой инструкции). Учитывая маркер, ядро должно было бы выполнить какой-то сложный контекстный поиск относительно этой конкретной ожидающей или находящейся в полете копии - такие операции лучше обрабатываются программным обеспечением, чем основным микрокодом. Что делать, если ОС нужно убить процесс и убрать все выполняемые и ожидающие операции memcpy? Как ОС узнает, сколько раз процесс использовал эту инструкцию и какие соответствующие токены принадлежат какому процессу?
--- РЕДАКТИРОВАТЬ ---
5) Другая проблема: любой механизм копирования вне ядра должен конкурировать в производительности необработанного копирования с пропускной способностью ядра для кэширования, которая очень высока - намного выше, чем пропускная способность внешней памяти. В случае пропадания кэша подсистема памяти будет в равной степени узким местом как для синхронизации, так и для асинхронной памяти. В любом случае, когда по крайней мере некоторые данные находятся в кэше, что является хорошим выбором, ядро выполнит копирование быстрее, чем внешний механизм копирования.