|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
Quoting Antonino Daplas (email@example.com): > > You mean the interrupt? The signal will always arrive at the right > > time. The kernel may not deliver the interrupt for some time after > > the signal arrives however. > > > Yes, the time interval from the arrival of the interrupt signal, waking > up the process, returning from the ioctl call, to processing the > registers. That was what I meant. > > Sleeping while waiting for an interrupt to arrive is very nice because > it gives the CPU to another process. Very good for systems where CPU > power and thoroughput is important. But this is not appropriate if the > process needs to get the signal immediately, or at least timely, manner. > The problem with this is during the wake_up(). Whether the process > wakes up now or a few hundred milliseconds later depends on so many > factors which the process nor the kernel can control. IE. If at the > time of waking up, the current process using the CPU was not a nice > player and it won't give back the cpu to the kernel, you get delayed. > If there are a lot of tasks waiting to wake up ahead of you, you get > delayed more. And if each of these tasks waiting ahead of you awakes, > each will take a few more precious CPU cycles to process what it was > sleeping for, and you get delayed more and more. And there is nothing > the kernel can do, because it cannot preempt. > > The worst part is that that each time you sleep, the time you actually > wake up will not be constant. It's actually better to have high, but > regularly timed latency, than relatively small but irregularly timed > latency. It's easy to compensate when latency is a known constant. > > A lot of the latency problems are being solved in linux-2.5 (O(1) > scheduler, preemption, workqueues, CPU affinity, punishing CPU hoggers, > rewarding nice players, etc) > > So, for things that are sensitive to latencies, you're better of polling > the registers directly, even just for testing purposes. Athough it > increases CPU usage a lot, it will factor out the latency part. Did you try sched_setscheduler (SCHED_RR) and setpriority (sched_get_priority_max()) ? I'm not sure if the process running during the interrupt occurs continues after the handler, but I think our process is the next to run after waking up. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.