From 1fa132931a3eed8556da801d9fe91aa4c166445e Mon Sep 17 00:00:00 2001 From: Kay Sievers Date: Fri, 24 Jan 2014 21:15:34 +0100 Subject: [PATCH] bus: bump memfd vs. copy limit to 512k to reflect recent benchmarks --- src/libsystemd/sd-bus/PORTING-DBUS1 | 8 ++++---- src/libsystemd/sd-bus/bus-kernel.h | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) 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. diff --git a/src/libsystemd/sd-bus/bus-kernel.h b/src/libsystemd/sd-bus/bus-kernel.h index 63df63e4b..e9f776d9f 100644 --- a/src/libsystemd/sd-bus/bus-kernel.h +++ b/src/libsystemd/sd-bus/bus-kernel.h @@ -44,7 +44,7 @@ /* This determines at which minimum size we prefer sending memfds over * sending vectors */ -#define MEMFD_MIN_SIZE (128*1024) +#define MEMFD_MIN_SIZE (512*1024) /* The size of the per-connection memory pool that we set up and where * the kernel places our incoming messages */ -- 2.30.2