|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
On Mon, 2002-12-09 at 19:21, Denis Oliver Kropp wrote: > > > > 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()) ? > Or just use 'nice'. > 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. > This one I'm not sure myself. The top-half is where the actual interrupt is handled. To minimize the load in the hard irq handler, a process can choose to do the main bulk of the work in the bottom-half (sleep_on()/wake_up() and family) -- this is not required, you can choose to do everything in the handler. Top-halves will have the highest priority, and will always be served, at the expense of the bottom half. So, if there are other processes that are still in queue in the bottom-half (woken up by a previous top-half) when your process wakes up from a top-half, it still has to wait. If you have the highest priority though, you will be moved at the top of the queue. So, if a slow or CPU-intensive process is running concurrently with a low-latency process, the low-latency process will suffer. Think jerky mouse movement and sound skips during disk activity. After that, the process can choose to continue to run (ie vsync_irq patch) or just sleep again and wait for the next event (most character drivers such as the mouse.) Tony -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.