It depends. If you have no active process on your system, I saw
times of interrupt + some work + context switch around 100us
or less (it's not exactly a context switch, anyway).
However, if there is any process running (such as a niced rc5des),
it seems it can take upto 10ms (next timer tick) for the reschedule
to happen.
I tried to set need_resched to 1, didn't help. I tried a
schedule() in the interrupt, gave an Aiee (which is quite
normal). I asked the question on comp.os.linux.development.system,
and I got a few ideas (yet to be tested):
- set the process as real-time process (looks like this is
really doing need_resched = 1)
- use a slow interrupt instead of a fast interrupt (?).
Any other ideas ?
This was with 2.0.35 on a pentium 75.
> By the way, I'm not interested so much in how fast it currently is - I'm
> interested in how fast it could be. So the fact that the driver may be
> crap and the networking stack is too slow, etc., isn't the point.
At least for now, I would say the main problem is the rescheduling.
But maybe I am completely mistaken and someone will be happy to
correct me :)
-
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.altern.org/andrebalsa/doc/lkml-faq.html