Hi, > 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. > sched_yield() could not work, because if vdr loop on it, the linux scheduler will think that vdr is an interactive process and will increase its priority and it will be worse. A solution could be to use nanosleep(1) instead of sched_yield(). Matthieu
