Subject: Re: [linux-audio-dev] huge latency peaks with 2.4.10-smp kernel
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Oct 19 2001 - 20:56:08 EEST
>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
This archive was generated by hypermail 2b28 : Fri Oct 19 2001 - 20:54:19 EEST