Didier Kryn <kryn@???> writes:
> Le 01/02/2016 22:38, Rainer Weikusat a écrit :
>> Didier Kryn <kryn@???> writes:
>>> Le 01/02/2016 17:52, Rainer Weikusat a écrit :
>>>> there's a known upper bound for the maximum number of objects which will
>>>> be needed
>>> Some applications need to asynchronously create and destroy large
>>> numbers of objects while the total number of objects at any given time
>>> remains bounded. Creating them in one function or in one thread while
>>> deleting them in another can be a sensible way to organize the program
>>> if allocation/deallocation is efficient.
>> Aha ... and what is this now supposed to communicate? It looks like a
>> couple of unrelated statements to me which also don't seem to have any
>> relation to the idea to use an array as 'backing store' for memory
>> allocation, as opposed to, say, something which allocates page (frames)
>> via OS calls, eg, mmap, and divides these as required or even just a
>> 'large' memory block acquired via malloc.
[...]
> a Data aquisition program, where a "producer" task reads blocks of
> data from digitizers and passes them to a "consumer" task which sends
> them over the network.
>
> The producer allocates the blocks of data inside an mmapped kernel
> buffer and the consumer frees them after use.
[...]
> The kernel buffer is necessary because the digitizer's data is
> transfered by DMA
[...]
> There's no point in allocating an unlimited memory size, because if
> the producer runs faster than the consumer it's quickly going to
> request all system memory.
Well, surely, if there's a particularly boring/ trivial application
where avoiding latency is not a primary concern[*] and flow-control is
necessary for ensuring that the producer doesn't overrun the consumer,
one possibility to implement that (likely dictated by the way the DMA
engine works) is to use a ring buffer to store 'data packets' (of some
definition). But J. Random network driver will usually use a ring buffer
of addresses/ control block containing addresses in order to learn where
the next frame is to be stored while data buffer themselves will be
dynamically allocated. Eg, a well-written network driver should enable
DMA directly into skbs which can then be passed upstack without further
copying while a less-than-well-written one might use an "array" of rx/tx
buffers and copy data into and out of these.
[*] As it's passing work from threads to other threads instead
performing it directly once a buffer has been received. This not
only adds communication overhead but (in the case of a
multiprocessor), additionally throws the content of the cache of the
receiving CPU away in order to reload the data into the cache of the
sending CPU.
::
Re: [DNG] Memory management strateg…
