On 25 May 2005 "Dr. Werner Fink" werner@suse.de wrote:
On Tue, May 24, 2005 at 11:01:50PM +0200, Matthias Schwarzott wrote:
On Tuesday 24 May 2005 19:15, Dr. Werner Fink wrote:
On Tue, May 24, 2005 at 04:31:31PM +0100, Darren Salt wrote:
I demand that Matthias Schwarzott may or may not have written...
in the last days I come accross a strange phenomen: One vdr thread eats up to 45% cpu on my Pentium3 700Mhz system when I did nothing with my vdr except live viewing on a ff card without transfer mode. Some digging resulted in this:
- The thread is the section handler thread.
- The cpu-load depends on the transponder currently watching on.
[snip]
Attached is a Patch to simply add one sleep(1) inte the loop before the poll. This results in reducing the cpu-load from 45% to 1.3%. And it does not seem to lose any sections.
If you replace that sleep(1) with sched_yield(), do you see the same effect wrt CPU load?
Wouldn't be pthread_yield() the better solution?
I tested sched_yield and pthread_yield and both did not change anything. The cpu load is the same as with an unchanged vdr.
Then two question rises: How often is this point of code reached and how often is the code after this point used all over the time? Maybe a solution with a condition variable to use a broadcast if a few sections are received for waking up the point would help.
As far as I see, only one section is read from a handle at a time. So the complete poll loop has to be done multiple times, even if allready several sections are waiting. So may be, it could be a solution to loop on a single handle until all sections are read (must work, as handles are non-blocking).
Regards.