From: Kay Sievers Date: Fri, 24 Jan 2014 20:15:34 +0000 (+0100) Subject: bus: bump memfd vs. copy limit to 512k to reflect recent benchmarks X-Git-Tag: v209~350 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=1fa132931a3eed8556da801d9fe91aa4c166445e;p=platform%2Fupstream%2Fsystemd.git bus: bump memfd vs. copy limit to 512k to reflect recent benchmarks --- diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 67af277..57339ee 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 63df63e..e9f776d 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 */