Messages in this thread | | | Date | Mon, 13 Mar 2000 14:29:08 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: Low latency and fbcon [0.5 sec is not considered low latency] [Re: new IRQ scalability changes in 2.3.48] |
| |
On Mon, 13 Mar 2000, Pavel Machek wrote:
> I tried doing something similar for fbcon, but could not. fbcon is by > far worst offender, and will happily block system for 500msec. if > (need_resched) schedule() does not work here. I tried adding > semaphores around fbcon entry points, but it does not seem to work.
i know about fbcon's latency problems, have you tried fixing the screen-scrolling function? It's by far the worst offender. Another function: if your card does bitblt and the bitblt command is posted to the videocard then typically the code polls the videocard status register to wait for the bitblt to finish - that can be long as well.
a semaphore plus a conditional reschedule in the above two places should already help. (also the semaphore has to be try_down_semaphore()-ed from the kernel-message function, because we obviously must not block in IRQ contexts which call printk.)
> (I replaced if (need_resched) schedule() with just schedule() -- I > hope that can not break anything...)
you have to add the semaphore (or semaphores) to the generic console code to be safe. The console code assumes that the individual lowlevel console functions are atomic (well, most of them). You should also probably boost the priority of the process holding this semaphore to the highest user-priority, otherwise console output can be blocked by normal processes. (If you manage to get this working, i'd be very interested in it.)
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |