Messages in this thread | | | Date | Fri, 25 Jun 1999 16:05:00 +0200 | From | Jamie Lokier <> | Subject | Re: Linux and Network Flight Recorder |
| |
Stefan Monnier wrote: > How far can you go with a mixed system where you switch dynamically between > polling and interrupts depending on the load ?
An interesting idea.
The problem there is once you have the polling code inserted into the application, it's difficult to _not_ poll. (If we were polling the device it might be worthwhile, but we're polling cacheable memory so it does not seem worthwhile to stop).
Perhaps it would be worthwhile to use interrupts when polling threads are not currently running, and to prefer scheduling those threads during heavy activity. It's not interesting for our work though -- our systems have heavy traffic all the time.
> Last I read anything along these lines, the switch was done rather simply: > at the end of an interrupt processing, a quick poll is used before going back > to `wait for interrupt' again.
Of course that's what we used to do, and what most folks do.
It doesn't get the same performance: much of our performance comes from (a) not handling interrupts at all and (b) doing light weight context switches at points convenient to the application -- no need to switch the full context.
Of course the zero copying is a big win in itself -- that's why it could well improve Linux performance to user zero copy.
> I'm sure you've looked into such an alternative (or you may even already use > it), so I'd be interested to know what was your experience with it,
Handling interrupts as soon as a new packet arrives is too much overhead on a current PC -- PC interrupts in general are a bit heavy. Even if you poll and loop within the handler.
Possibly deferring the interrupt for a while after the first packet might help (in the style of delayed ack). Then you can gather groups of packets _and_ the application can get on with its stuff.
-- Jamie
- 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/
| |