> i know about fbcon's latency problems, have you tried fixing the
> screen-scrolling function?
Thats a mess in more than one way. The code is design with have only one
card in your system in mind. Multihead it crokes.
> 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.
Accels help alot. Semaphore would be the best solution.
> 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.
Yep. This is one of the thing we are working on.
> 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.)
Me too. Email me the patch I will send it off to the linuxconsole project.
"Look its a text editor, no its a OS, no its Emacs"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
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:24 EST