vmsplice () e TCP
No originalvmsplice()
implementação, foi sugerido se você tivesse um buffer de área de usuário 2x o número máximo de páginas que poderiam caber em um pipe, um vmsplice () bem-sucedido na segunda metade do buffer garantiria que o kernel fosse feito usando a primeira metade do buffer.
Mas isso não era verdade, afinal, e particularmente para o TCP, as páginas do kernel seriam mantidas até receber ACK do outro lado. A correção foi deixada como trabalho futuro e, portanto, para o TCP, o kernel ainda teria que copiar as páginas do cana
vmsplice()
tem oSPLICE_F_GIFT
opção que meio que lida com isso, mas o problema é que isso expõe outros dois problemas - como obter páginas novas com eficiência do kernel e como reduzir a lixeira do cache. A primeira questão é que o mmap exige que o kernel limpe as páginas, e a segunda é que, embora o mmap possa usar o sofisticado kscrubdecurso no kernel, que aumenta o conjunto de trabalho do processo (lixeira em cache
Com base nisso, tenho estas perguntas:
Qual é o estado atual para notificar o usuário sobre a reutilização segura de páginas? Estou especialmente interessado nas páginas splice () d em um soquete (TCP). Aconteceu alguma coisa nos últimos 5 anos?Émmap
/ vmsplice
/ splice
/ munmap
a melhor prática atual para cópia zero em um servidor TCP ou temos opções melhores hoj