On 25 May 2005 "Dr. Werner Fink" <werner@xxxxxxx> 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. -- Stefan Huelswitt s.huelswitt@xxxxxx | http://www.muempf.de/
