On 28-03-24, 11:08, Arnd Bergmann wrote: > On Thu, Mar 28, 2024, at 06:55, Vinod Koul wrote: > > On 27-03-24, 16:03, Allen Pais wrote: > >> The only generic interface to execute asynchronously in the BH context is > >> tasklet; however, it's marked deprecated and has some design flaws. To > >> replace tasklets, BH workqueue support was recently added. A BH workqueue > >> behaves similarly to regular workqueues except that the queued work items > >> are executed in the BH context. > > > > Thanks for conversion, am happy with BH alternative as it helps in > > dmaengine where we need shortest possible time between tasklet and > > interrupt handling to maximize dma performance > > I still feel that we want something different for dmaengine, > at least in the long run. As we have discussed in the past, > the tasklet context in these drivers is what the callbacks > from the dma client device is run in, and a lot of these probably > want something other than tasklet context, e.g. just call > complete() on a client-provided completion structure. > > Instead of open-coding the use of the system_bh_wq in each > dmaengine, how about we start with a custom WQ_BH > specifically for the dmaengine subsystem and wrap them > inside of another interface. > > Since almost every driver associates the tasklet with the > dma_chan, we could go one step further and add the > work_queue structure directly into struct dma_chan, > with the wrapper operating on the dma_chan rather than > the work_queue. I think that is very great idea. having this wrapped in dma_chan would be very good way as well Am not sure if Allen is up for it :-) -- ~Vinod
