Ich habe mir gerade den neuen Zerocopy-Modus von Linux 4.14 angeguckt, um das in libowfat und gatling zu implementieren, aber habe mich dann entschieden, es doch nicht zu tun. Hier ist die Dokumentation dazu. Money Quote:...

BM-NBN5C4Fxxpiz2NWx1jjXovo7myq1pp1F
Nov 15 21:02 [raw]

<a href="https://blog.fefe.de/?ts=a4f71955">[l]</a> Ich habe mir gerade den neuen Zerocopy-Modus von Linux 4.14 angeguckt, um das in libowfat und gatling zu implementieren, aber habe mich dann entschieden, es doch nicht zu tun. <a href="https://github.com/torvalds/linux/blob/master/Documentation/networking/msg_zerocopy.rst">Hier ist die Dokumentation dazu</a>. Money Quote:<blockquote lang="en">Copy avoidance is not a free lunch. As implemented, with page pinning, it replaces per byte copy cost with page accounting and completion notification overhead. As a result, MSG_ZEROCOPY is generally only effective at writes over around 10 KB.</blockquote>Dieser Fall kommt nicht vor. gatling sendet einen kleinen Header, unter 1KB, und dann die Datei. Die Datei ist häufig größer als 10 KB, aber das Senden der Datei findet nicht per write oder sendmsg statt, sondern per sendfile, und das ist bereits zero-copy.<p>Ich könnte das für den Proxy-Modus implementieren, aber ehrlich gesagt sehe ich den Payoff nicht. Die Latenz kommt da nicht vom Kopieren sondern vom gzip der Daten, und dem https (im https-Modus geht zero-copy eh nicht, außer man macht Kernel-TLS, und das unterstützt im Moment noch niemand). In der Praxis halte ich die Auswirkungen von diesem Code daher für Null. Die Entwickler davon mussten auch einen synthetischen Benchmark bemühen, um einen Vorteil nachweisen zu können.<p>Ich ignoriere das jetzt mal, bis mir jemand zeigt, dass das was bringt.

[chan] fefe
BM-2cVf4AJ5E11LXpaHU19oQwAMPtynNjYRa5

Subject Last Count