Messages in this thread | | | Date | Sat, 05 Aug 2000 12:03:18 +1000 | From | Andrew Morton <> | Subject | Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5 |
| |
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 :)
- 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/
| |