Em Thu, 10 Jan 2013 03:06:51 +0100
thomas schorpp <thomas.scho...@gmail.com> 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 majord...@vger.kernel.org
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to