Messages in this thread | | | Date | Thu, 11 Dec 2008 09:43:05 -0700 | From | "Dan Williams" <> | Subject | Re: [PATCH 1/4 v2] dmaengine: add a tx_free method to struct dma_async_tx_descriptor |
| |
On Thu, Dec 11, 2008 at 8:55 AM, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > How does the struct's size impact their cache utilisation then?
Increasing the size may push some fields across a cache-line boundary leading to an additional cache-lines that need to filled/kept-coherent/etc... See pahole: http://lwn.net/Articles/206805/
> >> > And you mean, that increasing the size >> > of the struct by one pointer and letting users explicitly free those >> > descriptors when they want is worse than introducing a tasklet that will >> > have to periodically scan the list of descriptors while other hot paths >> > will move elements to and from this list, look for acked elements, lock >> > the list and free those elements? Periodically, because although we have >> > an event when to free them - on ioctl - there is no API to trigger that >> > tasklet. >> >> There are a few events that trigger this: completion interrupt, >> someone polls is_tx_complete, we run out of descriptors. > > Sorry, actually, it's not VIDIOC_DQBUF where we have to free buffer(s), > it's VIDIOC_STREAMOFF. And in a normal case there are no more completion > interrupts, no allocation requests, and noone is interested in > is_tx_complete. Normally you would just get a dma_release_channel after > that. Or, of course, the application may decide to restart capture, then > we get requests, completions, etc. again. So, yes, I could do this, it > just seems a bit unnatural to me.
Could the application tolerate another call to dma_request_channel when it restarts? I.e. just call dma_release_channel from the ioctl to clean everything up and not worry about another free() mechanism?
Thanks, Dan
| |