Linux-kernel mailing list archive 2000-32,: Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5

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

James Simmons (jsimmons@acsu.buffalo.edu)
Sun, 6 Aug 2000 20:57:46 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Marcelo Tosatti: "Re: 2.2.16 - Crash"
- Previous message: Jeffrey E. Hundstad: "Re: Can't get a block out edgewise"

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

Oops. I was thinking of the problems with latency when you cat a big file
to a tty. Especially with a fbdev driver. As for the interrupt latency. I
will have to work on that.
> 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.

Oh its quite a challenge. Everytime I think I solved a problem I
discover another limitation of the console system. The code is very old
and is completely designed around the idea of the VGA text mode hardware.
Now that linux supports many kinds of hardware it was a matter of
rethinking the abstracting of the console system. Especially if we want to
take advantage of the video hardware we have today. It is not that much of
a leap tho.
What is even worst is the whole vidoe subsystem. We have DRI/fbdv and
v4l all running independent of each other but yet each subsystem can have
a impact on other apps using the other 2 subsystems. Then we have the
console angle. So when thinking about the console design I have to take in
consideration the other video subsystems of linux as well. What a job but
it is well worth it.

> Good luck with the console project in 2.5 :)

Thanks. It should be another month before it is really ready for mass
testing.

Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their respective
owners.

James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.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/

- Next message: Marcelo Tosatti: "Re: 2.2.16 - Crash"
- Previous message: Jeffrey E. Hundstad: "Re: Can't get a block out edgewise"