Re: Maximum number of interruprs a CPU can receive without dropping/losing any
Rafi Gordon wrote:
>Hello,
> Thanks for the answer.
>
>
>
>>I suppose it is OS-, device-, and driver-dependent.
>>
>>
>
>You don't mention the CPU here directly.
>
Are you asking about the hardware or about the entire system? If you are
asking about the hardware, it is reasonable (I don't have any actual
knowledge) that each interrupt controller will only be able to hold so
many interrupts until it starts losing some. Read the docs on it for
details. You may find it sends a NMI before doing so.
> I assume the CPU and it's clock speed
>has also to do with the upper limit of interrupts from which on
>interrupts will be dropped.
>
OS, driver and CPU speed only have affect on the number of actual
interrupts the SYSTEM can handle. They affect the rate at which
interrupts are removed from the hardware queue, which affects the
overall rate at which interrupts can arrive.
Put another way, the amount of interrupts the interrupt controller can
cache affects the burst rate the system can handle, the driver OS and
CPU affect the sustained rate.
>A practical example which had driven me to post this question originally:
>I want to know when I should use NAPI (polling) instead of interrupts
>in a network
>card so that I won't loss interrupts. (and data , as a result).
>
>
This is where I stop following you.
First, I think it should be noted that the entire machine load affects
the maximal rate of data sending interrutps the system can handle. Even
the lowest priority user space program will require CPU eventually in
order to clear the kernel's buffers. What you have is a heirchy, where
the further you get, the less senstive you are for precise performance,
but you are still affected. If the userspace process does not get the
CPU in order to clear the kernel's buffers, the kernel will have to
start dropping data sooner or later.
But more importantly - I know of no network protocol that assumes that
each and every packet sent is also received at the other side. Such an
assumption is NEVER correct. As such, I think what you are trying to
achieve here is an over-optimized solution. Bear in mind that any CPU
time you use for polling is not used by the user-space process that
clears your buffers. As a result, you may find that polling actually
produces worse data yield than losing interrupts would.
>Is there a way, except experimenting, in which I can get to know , for
>different CPUs
>(with different clockspeed) ,when it is better to use NAPI (polling)
>instead of interrupts?
>
>
If my answer above proves correct then yes, there is. Constants definition:
cs - cpu speed (in Mhz).
ib - number of interrupts the interrupt controller can buffer
km - size that the kernel can allocate for storing buffers (in MB)
ur - rate at which userspace can use up data (in MB/million cycles)
kc - number of cycles that it takes the kernel to handle each interrupt
uc - number of cycles that it takes the user space to handle each interrupt
poll - the poll efficiency factor. You should probably switch to polling
if this number is above 0.5 or 0.8:
And the actual formula is:
poll=0
>-- RG
>
>
Shachar
--
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
=================================================================
To unsubscribe, send mail to linux-il-request@... with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@...
RSS Feed