>I don't like the way it's done. Mainstream goes digging latency holes all >the time and small group of people is running after and trying to fill those >holes. I'd like to see more co-operation and less one-eyed way of doing >things.
agreed. but this is happening less and less. Ingo, Andrew and now Richard's work is making many more people think about scheduling latency issues. this would never have happened without their demonstrating the amazing effect of their patches. >That's why he should be thinking about every feature "how this affects >throughput and latency". If it increases throughput by 10% but causes >latencies to raise by order of magnitude that "improvement" should be >dropped. there are many, many users of the linux kernel who would not agree with you at all about this. probably even the majority. >Yes there is, virtual interrupts with priorities. Higher priority interrupts >go over lower priority ones and interrupts are never disabled at hardware >level. You *have* to disable them at the h/w level. You can do it for a very short time, but it still has to be done: you cannot service one IRQ while another IRQ is already being processed. Its just impossible without writing incredibly hideous code. I know, because I've done it, and trust me, its not worth it. A fully instruction-level preemptable context switch? Been there, done that, don't want to go back. > Kernel should buffer interrupts. Something like RT-Linux does for the >Linux kernel. Linux is not RTLinux. The core kernel code does not claim ownership of all interrupts. Thats what device driver interrupt routines are for. It just so happens that despite the presence of a very nice design for fast interrupt handling, many people, including some people who should know better, have written interrupt handling systems that don't do the right thing. It doesn't seem reasonable to me to respond to this situation by saying: "because programmer X didn't do the right thing in a *device driver* (not an application), Linux must take over total responsibility for hardware interrupts". That adds code to the common case to solve a specific problem caused by someone's bad design. Linus, myself and many others would never agree to such a poor decision. > We could also do some parallel interrupt processing in SMP >machines ala RT-Linux. Soundcard interrupts could be fed to CPU #1 while >everything else is handled by CPU #0. There are patches to do task binding to processors, which is closer to what you want than IRQ binding. But they slow down the common case, and they are therefore not in the main kernel. >Kernel could also disable badly behaving driver. Once too long in driver and >*bang* driver is unloaded and device disabled. Ouch. You mean instrument every place where we block and unblock interrupts? Linus and 99.9% of the rest of the world are going to really love that! And besides, most of the places that concern us are not just in drivers, but in the VM system. Note that there are also h/w designs that are impossible to use in a low latency system: even BeOS warned against any use of *any* joystick driver on their kernel for precisely this reason. Certain MIDI implementations (*cough*sblive*cough*) could be considered in the same category. Are their drivers "badly behaved", or do you as a user, have to understand the implications of using them? The point is to identify such pieces of code, and make sure people know about them, ideally to the point of someone (the original author, or not) rewriting the code in question and/or making sure users know the implications. --p
