Em Thu, 10 Jan 2013 03:06:51 +0100 thomas schorpp <thomas.schorpp@xxxxxxxxx> escreveu: > On 09.01.2013 22:30, Nikolaus Schulz wrote: > > On Tue, Jan 08, 2013 at 12:05:47PM +0530, Soby Mathew wrote: > >> Hi Everyone, > >> I have a doubt regarding about the global mutex lock in > >> dvb_usercopy(drivers/media/dvb-core/dvbdev.c, line 382) . > >> > >> > >> /* call driver */ > >> mutex_lock(&dvbdev_mutex); > >> if ((err = func(file, cmd, parg)) == -ENOIOCTLCMD) > >> err = -EINVAL; > >> mutex_unlock(&dvbdev_mutex); > >> > >> > >> Why is this mutex needed? When I check similar functions like > >> video_usercopy, this kind of global locking is not present when func() > >> is called. > > > > I cannot say anything about video_usercopy(), but as it happens, there's > > a patch[1] queued for Linux 3.9 that will hopefully replace the mutex in > > dvb_usercopy() with more fine-grained locking. > > > > Nikolaus > > > > [1] http://git.linuxtv.org/media_tree.git/commit/30ad64b8ac539459f8975aa186421ef3db0bb5cb > > "Unfortunately, frontend ioctls can be blocked by the frontend thread for several seconds; this leads to unacceptable lock contention." > Especially the stv0297 signal locking, as it turned out in situations of bad signal input or my cable providers outtage today it has slowed down dvb_ttpci (notable as OSD- output latency and possibly driver buffer overflows of budget source devices) that much that I had to disable tuning with parm --outputonly in vdr-plugin-dvbsddevice. > > Can anyone confirm that and have a look at the other frontend drivers for tuners needing as much driver control? > > I will try to apply the patch manually to Linux 3.2 and check with Latencytop tomorrow. Well, an ioctl's should not block for a long time, if the device is opened with O_NONBLOCK. Unfortunately, not all drivers follow this rule, and blocks. The right fix seem to have a logic at stv0297 that would do the signal locking in background, or to use the already-existent DVB frontend thread, and answering to userspace the last cached result, instead of actively talking with the frontend device driver. Both approaches have advantages and disadvantages. In any case, a change like that at dvb core has the potential of causing troubles to userspace, although I think it is the better thing to do, at the long term. > > y > tom > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
