Re: [Linuxconsole-dev] Low latency for fbcon (fwd)

[Petr V. <VAN...@vc...>]

On 16 Mar 00 at 21:07, James Simmons wrote:
> From: Pavel Machek <pa...@su...>
> To: lin...@bu..., lin...@su..., mi...@ch...,
>      jsi...@ac...
> PS: Would it be possible to declare that fbcon is re-entrant, but may
> mess the screen up in such case?
No. Accesses to accelerators cannot be interrupted. But it is possible
to place down_trylock around them... 
> + * Bigger buffer means better console writing performance, but worse
> + * latency of console switches.
> -char con_buf[PAGE_SIZE];
> -#define CON_BUF_SIZE   PAGE_SIZE
> +#define CON_BUF_SIZE   (PAGE_SIZE/10)
> +char con_buf[CON_BUF_SIZE];
Is not 400 too small? It is ~3 lines...
> +static int softint_missed = 0;
> -static void console_softint(unsigned long ignored)
> +static void console_softint(unsigned long ignored)
> +{
> +   run_task_queue(&con_task_queue);
> +   softint_missed = 1;
> +   if (down_trylock(&console_sem)) {
> +       printk( "console_softint request dropped\n" );
Is it really good idea to do printk() when console_sem is held?
> -       spin_unlock_irq(&console_lock);
>         ret = copy_to_user(buf, con_buf_start, orig_count);
You do not have to have locked console here... You need only
exclusive access to console copy buffer, but not to console 
code itself. All code should check for console changes as copy_to_user
can sleep (and vc_screen copy to/from vcs does this checks).
                                                Best regards,
                                                        Petr Vandrovec
                                                        van...@vc...