Em Wed, 30 Jan 2019 11:56:58 -0300 Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> escreveu: > 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. I suspect that just using a separate mutex for open/release could be enough to make the upstream version stable, when multiple instances are running. However, it has been a challenge for me to debug it here, as I'm traveling with limited resources. I'm using the same machine for both desktop, to run a VM to access some corp resources and to do Kernel devel. That's usually a very bad idea. Yet, I'm pretty sure that after this patch, things are stable, as I've been able to test it without any issues and without needing to reboot my machine. If you have enough time, feel free to test. Otherwise, I intend to just apply this patch series, as it fixes a few bugs and make vim2m to actually display what it would be expected, instead of plotting just some weird image that the current version shows. Cheers, Mauro
