bus: bump memfd vs. copy limit to 512k to reflect recent benchmarks
This commit is contained in:
parent
5a081409c5
commit
1fa132931a
|
@ -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.
|
||||
|
||||
|
|
|
@ -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 */
|
||||
|
|
Loading…
Reference in a new issue