Messages in this thread | | | Date | Mon, 13 Mar 2000 14:17:16 +0100 | From | Pavel Machek <> | Subject | Re: Low latency and fbcon [0.5 sec is not considered low latency] [Re: new IRQ scalability changes in 2.3.48] |
| |
Hi!
> > 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.
I already know offenders, I just don't know how to fix them.
> 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
Oops, that's the trick. I added semaphore on fbcon layer -- which is probably bad idea.
> 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.)
I'll try it again. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
- 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/
| |