Hey Mauro, On Wed, 2019-01-30 at 11:19 -0200, Mauro Carvalho Chehab wrote: > Em Wed, 30 Jan 2019 09:41:44 -0300 > Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> escreveu: > > > On Tue, 2019-01-29 at 14:00 -0200, Mauro Carvalho Chehab wrote: > > > It doesn't make sense to have a per-device work queue, as the > > > scheduler should be called per file handler. Having a single > > > one causes failures if multiple streams are filtered by vim2m. > > > > > > > Having a per-device workqueue should emulate a real device more closely. > > Yes. > > > But more importantly, why would having a single workqeueue fail if multiple > > streams are run? The m2m should take care of the proper serialization > > between multiple contexts, unless I am missing something here. > > Yes, the m2m core serializes the access to m2m src/dest buffer per device. > > So, two instances can't access the buffer at the same time. That makes > sense for a real physical hardware, although specifically for the virtual > one, it doesn't (any may not make sense for some stateless codec, if > the codec would internally be able to handle multiple requests at the same > time). > > Without this patch, when multiple instances are used, sometimes it ends > into a dead lock preventing to stop all of them. > > I didn't have time to debug where exactly it happens, but I suspect that > the issue is related to using the same mutex for both VB and open/release > instances. > > Yet, I ended by opting to move all queue-specific mutex/semaphore to be > instance-based, as this makes a lot more sense, IMHO. Also, if some day > we end by allowing support for some hardware that would have support to > run multiple m2m instances in parallel, vim2m would already be ready. > I don't oppose to the idea of having a per-context workqueue. However, I'm not too comfortable with having a bug somewhere (and not knowing whert) and instead of fixing it, working around it. I'd rather fix the bug instead, then decide about the workqueue. Thanks, Eze
