[vdr] Re: Kernel-Patch to make VDR undisturbable

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

On Saturday 06 April 2002 23:30, Matthias Loetzke wrote:
> Andreas Schultz (aschultz@cs.uni-magdeburg.de) schrieb:
> > rt sheduling still allows the program to
> > wait for I/O operations and to give up it's time slice.
>
> But if the programm does not want to give up the time-slice it will be
> chosen by the scheduler again and lock out any lower-priority process for
> the CPU.

/bin/agree

> > During wait for I/O
> > operations, the kernel will automaticly (as always) give the CPU to some
> > other process.
>
> Only if there are no other realtime processes on the runqueue. With two
> DVB- cards VDR uses up to 9(?) processes, which would be scheduled next if
> one of them is willing to get the CPU. One bug in VDR could hang the whole
> computer.

/bin/agree  - but we might be able to build in some safeguards

> > If you have to wait inside the program you just have to avoid
> > busy wait loops.
>
> ACK.
>
> > Doing this is not really difficult.
>
> ACK
>
> > Things like blocking reads/writes, poll/select, mutex_lock() on locked
> > mutexes, cond_wait will automaticly allow lower priority processes to
> > run.
>
> Imagine a slow box like mine, which may not have the power to complete the
> operations in the kernel (may be heavy network I/O) and VDR (i.e. doing
> time- shifting) at the same time. In this case the box would be blocked
> until I plug off the network or stop VDR which might be impossible in this
> case, because I can not interact with VDR. RT-processes which do not
> guarantee the return of the CPU to SCHED_OTHER processes within a short
> time frame will make it hard to use the box for any user interaction.

Ahh, i think i see where this is going. I was thinking along a different line. 
My basic assumtion was that the box used *always* had enough power to finish 
all current vdr tasks and still has time left for interactive processes.
An underpowered box will *never* run vdr undisturbed no matter how you 
schedule. But with rt sheduling it will lock out all other process, thereby 
starving all non rt-apps to death.
I think there is no way to eat both cakes. You either can have rt guarantees 
on the posible expense of anything else (thats what my patch does) or unfair 
schedulung that highly favours vdr but does not give guarantees (IMHO your 
patch).

> > I have tested my buffer syncing patch with SCHED_FIFO and it works so
> > far. Even heavy disk activity during replay doesn't disturb the output
> > any more.
>
> Sounds good. Go ahead with your work. I am willing to try you solution.

one small correction though, heavy disk activity (copying a 2GB file on the 
same disk/partition) does disturb playback, heavy CPU activity (unrar, unzip) 
does not. IMHO can nothing in linux currently shield you from the disk 
problem. The block device elevator algorithm does not use any process 
priorities. Our read/write requests can therefore be delayed beyond the safty 
margins, resulting in overflows to vdr's internal buffers.
I think XFS has some aproaches to solve this, i'll look into that a bit more.

> > IMHO, this is not as difficult as you suggest. Much of it will only be a
> > cleanup the current locking and syncing stuff - which is needed anyway.
>
> I am not as optimistic as you. It is a complex programm, and you have to
> make sure that under any circumstance VDR will not take full use of its
> time- slices while on the runqueue.

One solution might be to put the main loop and remote/keyboard I/O control 
threads on a higher priority. This will allow one to at least exit vdr, even 
if the more complicated playback threads do lockup.

Andreas