>> In short, I'd much rather see a patch that
>>
>> (a) gets rid of the "fast" vs "slow" interrupts. They used to make sense,
>> but they don't much do that any more. They only result in problems.
>>
>> (b) make the interrupt handler routine return a flag whether we should
>> do bottom half processing after this interrupt. This flag is "or"ed
>> together for all shared interrupts, and upon exit from the interrupt
>> we then decide whether we should do the bottom half or not.
>>
>> (c) make "ret_from_interrupt" be different from "ret_from_sys_call",
>> because we no longer want to return to ret_from_sys_call() because we
>> already did bottom half handling.
I have a patch prepared that does pretty much exactly this. The only
difference is that unlike Linus, I don't have the authority to "get rid"
of things from the Linux kernel. I've added "adaptive" interrupt handlers,
but I haven't got rid of anything. However, if "adaptive" interrupt
handlers were to be adopted as a standard Linux facility, it would
then be an easy thing over a period of time to gradually migrate all
the existing fast and slow handlers over, and when there were no fast
and slow handlers left in any device drivers, support for those could be
removed, leaving us with a single unified interrupt handling mechanism.
>> And after the above patch, speeding up slip/ppp latency is just a matter
>> of returning 1 in the serial interrupt handler when we have a full packet.
Precisely. I also have a patch that does this.
Ted Ts'o wrote:
>> The bottom line is that you can't just say that 1.54 usecs is a small
>> amount of overhead, because in the serial driver, you get a lot of
>> interrupts. Although it might not be obvious, the interrupt routines
>> *are* part of a tight loop. :-)
I agree with Ted here. It's very dangerous to make assertions about
what's small and what's large because circumstances differ so widely.
Someone might want to use Linux on a slow CPU, or with some hardware
that interrupts at a very high rate (or both). If we can easily make that
possible for those users (by only taking the full signal-handling return
from interrupt routines when necessary) then I think we should do so.
Alan Cox wrote:
>> You rejected one of those prior to 1.2 that came from the STRIP driver
>> authors.
and Linus Torvalds replied:
>> Yes. Note the "prior to 1.2". People have had patches like this
>> floating around for quite some time, but the timing has been bad. I
>> think I actually got a similar patch just before 2.0 too - and I'm
>> definitely not likely to change basic irq behaviour before making a
>> stable release.
Yes, Linus, I've been unlucky here. Both times I sent you the patch
turned out to be times when you were not able to make those kinds of
changes to the kernel. I didn't regard it as wasted effort though,
because we needed it for our research anyway. To be able to make accurate
performance measurements of the Metricom radios we had to make the packet
delivery delay consistent. By waiting for the next timer tick to deliver
the data, the standard serial drivers effectively add a random delay of
0-10ms to each packet. When we were trying to measure times to the
milisecond, having 10ms of noise on all our timings made it impossible
to get good measurements, so that's why I had to do something about it.
The good news is that our accurate measurements led to Metricom being
able to triple the performance of their radios, from about 35kbit/sec
to 110kbit/sec. This patch (and others) is now maintained on our web site
at <http://mosquitonet.Stanford.EDU/software/LinuxChanges.html> and you
are welcome to pick it up at your convenience.
Ted Ts'o wrote:
>> If it's the one that I'm thinking of, I can't blame Linus; they added
>> yet another kind of interrupt, which they called "adaptive", and the
>> code did things like (in the assembly stubs defined in irq.h), had some
>> hard-coded comparisons to see if the IP was the serial interrupt
>> handler, and other really, really unclean stuff.....
>>
>> So, I think Linus wants it done, but wants it done right. :-)
I really object to this kind of mud-slinging. You've repeatedly
attacked my code in private e-mail Ted, and now you've taken to
attacking it on public mailing lists. I don't know why you're so
hostile. As I've explained to you before, we needed to eliminate the
random noise from our measurements, so I wrote these patches. I offered
them to you as a contribution to the Linux community, and you refused
them. That should have been the end of it, but you keep wanting to
attack it.
To answer your points:
1. they added yet another kind of interrupt, which they called "adaptive"
We added yet another kind of interrupt because that was the least
intrusive way to make the patch. As I explained, if this were to be
officially adopted, it would *REDUCE* the number of kinds of interrupts
from two to one.
2. hard-coded comparisons to see if the IP was the serial interrupt
handler, and other really, really unclean stuff.....
You're talking about the patch to diagnose serial overruns, which is
totally unrelated to this thread of discussion, so why bring it up?
This thread is about simplifying interrupt architecture and reducing
serial port latency.
Our "adaptive" interrupt patch adds about 160 lines of code which is
very clean and logical, and would remove twice that much if it were
adopted officially as a replacement for the old fast/slow architecture.
Our "fast serial" patch changes about 15 lines and adds about 90 (most
of which are comments explaining what it's doing). You may not like it
because it returns a status indication instead of running the task
queue directly out of the serial driver like your design, but to
call it "really, really unclean stuff" is unneccessarily insulting.
I'm just an end-user out here. I'm not one of the Linux inner circle.
When from time-to-time I run into problems with Linux, I try to fix them.
If I succeed, I try to make a contribution back to the Linux community.
That's all. Our Web site has a page with our patches on it, which are
available to whoever wants to make use of them.
http://mosquitonet.Stanford.EDU/software/LinuxChanges.html
Stuart Cheshire <cheshire@cs.stanford.edu>
* <A HREF="http://ResComp.Stanford.EDU/~cheshire/">World Wide Web Page</A>
* Stanford Operating Systems and Networking Group Research Assistant
* Stanford Residential Computing Associate
* Macintosh Programmer