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/