[vdr] performance during cutting

[thees@informatik.uni-kl.de]

Hi,

On my machine sometimes it takes nearly 30 seconds to read the
recordings-list while cutting is in progress. Sometimes vdr even gets 
a timeout and restarts. Also cueing is nearly impossible. 

I already tried to slow down the thread by inserting 
usleep()-calls with several times, but I think
the main problem is the caching strategy of the kernel/filesystem. There
is no direct means to get informations about the cache-write-back status
in order choke the cutting thread for better main-thread reactivity
(e.g. to read the redordings-list). 

But we can see how long file-I/O operations take in order to guess the 
I/O-load. So here is my suggestion:

1.  There are priority- (i.e. foreground) and background-I/O operations. 
    Priority-I/O is recording, playback, etc.
    Backround-I/O is cutting, writing EPG, etc.

2.  We bracket every priority-I/O-call with two function calls:
	    start_foreground_io()
	    read(...) / write(...) / open(...) / close(...)
	    end_foreground_io()

3.  We precede every background-I/O-call with a function call:
	    start_background_io()
	    read(...) / write(...) / open(...) / close(...) 
    (perhaps also a call to end_background_io() for better readability)

4.  In start_foreground_io()/end_foreground_io() we measure the time for 
    every I/O-operation and keep a statistics (e.g. sliding average) for it.

5.  When this sliding average exceeds a certain time (e.g. 100 ms) the
    filesystem write back caches may be full and we have to choke the 
    background-I/O for some time by calling [u]sleep(...) 
    (remeber its a background-thread!).

So this system could control the average delay of the foreground thread
by choking the background I/O-rate.

- There are some refinements: The sleep-time could be modified softly 
  e.g. by some kind of PI-regulator.

- the start_*_io()-functions could get additional informations about the
  type and amount of I/O (e.g. the number of bytes to be written).

- In C++ the calls to start_*_io() and stop_*_io() can be done
  implicitly by the constructor and destructor of a temporary object:

	// doing some stuff
	
	{	// braces just to limit lifetime of tmp_dummy: 
	
		ForegroundIO tmp_dummy; 
		write(...); 
	}
	
	// doing other stuff

  This will cause ForegroundIO::ForegroundIO() to be called before
  write() and ForegroundIO::~ForegroundIO() afterwards.
    
What do you think about this?

Greetings,

Joachim

-- 
 --------------------------------------------------
 Joachim Thees <thees@informatik.uni-kl.de>
 Univ. of Kaiserslautern, Computer Networks Group
 --------------------------------------------------