[zeromq-dev] Memory management
steven.mccoy at miru.hk
Thu May 14 10:57:22 CEST 2009
2009/5/14 Martin Sustrik <sustrik at fastmq.com>
> Per Peer vs. Per Transport.
>> With a ring buffer we are permanently tying the memory to the transport
>> and we impose a ceiling on the number of packets that can be used. Buffers
>> are currently pulled from the slab or trash stack for each receive window on
>> demand. If a ring buffer is allocated per peer we may see a significant
>> problem with peers bouncing up and down due to long expiration periods and
>> no supported OPT_FIN notifications. This suggests a fixed buffer for the
>> entire transport to share between all peers, the implication being variable
>> window sizes for each peer and additional complexity of handling windows
>> that must be shrunk. Should the buffer be equally split among peers, on a
>> first come first serve basis, etc?
> Peer = multicast group, right? If so, we don't really care as with 0MQ
> there no way to use one transport with multiple multicast groups.
Peer means other application on the network, so in the case of a receiver, a
peer is any sender on the network. For example how is fail over managed,
one peer is sending traffic then disappears, another peer starts sending
traffic - there are now two active receive windows.
>> The slab allocates blocks of memory aligned as preferred by the underlying
>> architecture. Using a ring buffer and arbritarily slicing up blocks can
>> make paging worse as multiple requests might be needed for one buffer. One
>> solution is to implement a hybrid design that allocates page size and
>> alignment friendly blocks of memory.
>> wide stack.png
>> This could still be implemented in a stack or a ring buffer, reference
>> counting can be used for individual slices of a chunk.
> Page Cache Friendly.
> Sorry, I'm lost here. What do you mean by "multiple requests might be
> needed for one buffer"?
If you have an 4KB page and a 4KB object but 1KB is in one page, 3KB in the
next page, you end up with twice the overhead of when the object neatly fits
in one page.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev