vmsplice () и TCP

В исходной реализации vmsplice () , было предложено , что если у вас есть буфер области пользователя 2x максимальное количество страниц, которые могут поместиться в конвейер, успешная vmsplice () во второй половине буфера будет гарантировать, что ядро ​​было выполнено с использованием первой половины буфера.

Но это было не так, в конце концов, и особенно для TCP, страницы ядра будут храниться до получения ACK с другой стороны. Исправление этого было оставлено как работа в будущем, и, таким образом, для TCP ядру все равно придется копировать страницы из конвейера.

vmsplice () имеет параметр SPLICE_F_GIFT , который вроде как работает с этим, но проблема в том, что это обнажает две другие проблемы - как эффективно получить свежие страницы из ядра и как уменьшить количество мусора кеша. Первая проблема заключается в том, что mmap требует, чтобы ядро ​​очищало страницы, а вторая проблема заключается в том, что, хотя mmap может использовать причудливую функцию kscrubd в ядре, которая увеличивает рабочий набор процесса (очистка кеша) .

Исходя из этого, у меня есть следующие вопросы:

• Каково текущее состояние уведомления пользовательского пространства о безопасном повторном использовании страниц? Меня особенно интересуют страницы splice () d в сокете (TCP). Что-нибудь произошло за последние 5 лет?
• Является ли mmap / vmsplice / splice / munmap текущей лучшей практикой для нулевого -копирование на TCP-сервере или у нас есть лучшие варианты сегодня?