Date: Mon, 29 Oct 2001 02:17:37 +0530 From: "murthy kn" <knmurthy30@hotmail.com> To: rizzo@aciri.org Cc: net@FreeBSD.ORG Subject: Re: Polling vs Interrupts (was Re: NEW CODE: polling support...) Message-ID: <F49U8cJHiR2CYDksLPe0001d8ac@hotmail.com>
next in thread | raw e-mail | index | archive | help
Hi,
First, let me thank for the nice detailed description
of polling vs interrupts.
I have a couple of questions.
>
>As the load level increases, your interrupt rate also grows, and
>so does the work that you perform in each call to XX_intr().
>
>The increase in interrupt rate is dangerous because it can make
>you waste a large fraction of your CPU cycles just in overhead and
>context switches, leading to a steep drop of the forwarding rate
>as the offered load increases.
>
>The growth in interrupt rate is typically sublinear in the incoming
>packet rate, because as the latter increases, it becomes more and
>more likely that you get to process a second packet before you can
>complete the interrupt service routine.
>
>This might seem a good thing; but unfortunately, there migth be a
>third packet, and a fourth, and a fifth... and so you might remain
>within your interrupt service routine for a very large amount of
>time (potentially unbounded). This is what makes the system
>unresponsive under load, and prevents a fair sharing of resources
>among devices.
---------->
1. What will happen if a packet some packets arrive DURING the
current call to XXX_intr() - are they processed by the
current invocation of XXX_intr() itself without generating a new interrupt
or will there be a seperate interrupt for each of those packets ? (
basically, I see a "rcvloop" in the driver code (fxp))
2. If the answer to the (1) is true, I am not getting the difference
between interrupt mitigation/ coalescing described below and the above
explanation. Basically, what is being done above is also reducing the number
of interrupts (and hence context swithcing overheads) by processing multiple
packets in the same call to XXX_intr() ?
So, why this kind of becomes a bottleneck whereas interrupt
mitigation increases the performance.
>write into the status register) and process all events that might have
>triggered it -- if you stop early, there might not be another
>interrupt that wakes you up to continue the leftover work, so you
>have to set a timeout by independent means, or resort to polling.
>
>
>As an example, for a simple I/O read from a register on a PCI card,
>I have often measured times as high as 10,000 clock cycles (for
>our 750MHz host, this is over 10us) during which the CPU cannot do
>anything. Unfortunately, this time is totally unpredictable, and
>the CPU has no way to abort the transaction once started.
--------> Any pointers on tools/techniques to perform such measurements for
instrumenting the kernel will be very helpful.
Thanks,
Murthy
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F49U8cJHiR2CYDksLPe0001d8ac>