Le 02/02/2016 16:42, Rainer Weikusat a écrit :
> 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.
>
>
Well hacking J Random network driver is a much much more ambitious
task for a programmer, at least for me, than performing the necessary
ioctls to allocate and mmap a kernel buffer and do VME transfers :-)
Didier
::
Re: [DNG] Memory management strateg…
