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

[Pavel M. <pa...@su...>]

Hi!

> > 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... 

Well, then critical sections around accelerator could be wrapped in
spin_lock_irq...

> > + * 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...

No. Scrolling 3 lines takes _lots_ of time.

> > +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?

Yes. It _must_ work that way.

> > -       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

I know, but I do not care: copy_from_user is faster operation than
scrolling.

> 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).

								Pavel
-- 
I'm pa...@uc.... "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at di...@li...