polling decreases throughput ~50%

[Chuck Swiger]

Bill Campbell wrote:
> On Tue, Aug 02, 2005, Victor Semionov wrote:
[ ... ]
>>I was uploading some large file to my neighbor's windows box. With polling 
>>disabled, the transfer rate was 8 MB/s and CPU usage was 90%. I turned on 
>>polling with sysctl and CPU usage decreased to 50%, which I expected, but 
>>also the transfer rate dropped to 4.5 MB/s, about half. The numbers are 
>>approximate. The interface is a RealTek (rl driver). No background jobs were 
>>running. kern.polling.* all defaults.

What is kern.hz set to?  Does increasing it improve throughput?

>> Why is that? I thought polling should decrease CPU usage by avoiding too many 
>> context switches when a hw irq is generated frequently, but it shouldn't make 
>> the transfer slower if there are no other jobs running.

You have to poll often enough to keep the pipe full, otherwise your max 
throughput can be limited.  Also, rl hardware isn't the greatest and probably 
requires a lot more CPU than a device with working buffer/DMA design.

> I certainly don't claim to be an expert on this subject so take this with a
> grain of salt.
> 
> Interrupts were originally created to eliminate the need for polling
> allowing processes to sleep until an interrupt occurs rather than having
> the process in a loop testing to see if any input is ready or the device is
> available for further work.

Blocking was created to eliminate the need for polling/sitting in a loop 
testing a condition.  Interrupts were created to take the CPU away from normal 
processing in order to attend a high-priority, time-critical condition or 
signal which can't wait.

A good serial chip/UART, or a NIC receiving packets, shouldn't fire an 
interrupt just because a character/packet came in, they should fire an 
interrupt when their SILO/buffer is getting full or has some data which hasn't 
been serviced in a while.  ("Interrupt coalescing")

-- 
-Chuck