X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=src%2Flibsystemd%2Fsd-bus%2FPORTING-DBUS1;h=57339ee268ca6726f77684de4d6b326a9c35a191;hp=67af27772eec49dcb893aacf143583fdf33b76bb;hb=1fa132931a3eed8556da801d9fe91aa4c166445e;hpb=5a081409c5b88b0fcffb4ee5a0e07ed133ca4da3

diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1
index 67af27772..57339ee26 100644
--- a/src/libsystemd/sd-bus/PORTING-DBUS1
+++ b/src/libsystemd/sd-bus/PORTING-DBUS1
@@ -172,15 +172,15 @@ which items are contained in the message is left untouched.
 PAYLOAD_MEMFD items allow zero-copy data transfer (see below regarding
 the memfd concept). Note however that the overhead of mapping these
 makes them relatively expensive, and only worth the trouble for memory
-blocks > 128K (this value appears to be quite universal across
+blocks > 512K (this value appears to be quite universal across
 architectures, as we tested). Thus we recommend sending PAYLOAD_VEC
 items over for small messages and restore to PAYLOAD_MEMFD items for
-messages > 128K. Since while building up the message you might not
+messages > 512K. Since while building up the message you might not
 know yet whether it will grow beyond this boundary a good approach is
 to simply build the message unconditionally in a memfd
 object. However, when the message is sealed to be sent away check for
-the size limit. If the size of the message is < 128K, then simply send
-the data as PAYLOAD_VEC and reuse the memfd. If it is >= 128K, seal
+the size limit. If the size of the message is < 512K, then simply send
+the data as PAYLOAD_VEC and reuse the memfd. If it is >= 512K, seal
 the memfd and send it as PAYLOAD_MEMFD, and allocate a new memfd for
 the next message.