Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5

[Andrew M. <an...@uo...>]

James Simmons wrote:
> 
> > > > - I haven't tested fbdev - Pavel says it's bad.
> > >
> > > thats pretty unsolvable (just as the serial console latencies), the
> > > console layer assumes atomicity.
> >
> > Yup.  console can block _interrupts_ for 2 millisecs, which is much worse
> > than scheduling delays (network Rx overruns).
> 
> I have been thinking on how to deal with this as well. In do_con_write it
> breaks up the writes into CON_BUF_SIZE. During each loop we could test for
> current->need_sched. Break the lock if needed and schedule() then reset
> the console lock. To prevent lost messages we could even use the
> con_task_queue.

mm.. There are two fairly separate requirements here - the first is to not
block interrupts for so long.  The need_resched/schedule() requirement is
icing on that cake and IMO comes a long way behind in importance.  I guess
you can bird both these stones at the same time.

BTW, it's fun to say rude things about the console code but we should
understand that it is a difficult problem.  Memory-mapped video displays are
schizophrenic: they are character devices and hence should talked to via
queues.  But they're fast and random access, so we also want synchronous
write semantics.  But they're stateful so we end up where we are today.

Good luck with the console project in 2.5 :)