Le 02/02/2016 16:42, Rainer Weikusat a écrit :
Didier Kryn <[email protected]> writes:
Le 01/02/2016 22:38, Rainer Weikusat a écrit :
Didier Kryn <[email protected]> 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
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
