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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:25 EST