[zeromq-dev] Memory management

[Steven McCoy]

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.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090514/11a51142/attachment-0001.htm