polling decreases throughput ~50%

[Garrett Cooper]

Danial Thom wrote:

>--- Victor Semionov <victor at vmpbg.com> wrote:
>
>  
>
>>>>>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.
>>>      
>>>
>>HZ is 1000, which I guess should be more than
>>enough with 
>>kern.polling.burst_max=150.
>>
>>Indeed, it was hardware's fault - my other NIC
>>is a fxp and I got much better 
>>results with it - less CPU, while throughput
>>stayed the same as without 
>>polling.
>>    
>>
>
>Great. So you've added 900 totally unnecessary
>context switches, plus all of the rubbish that
>gets done every clock tick, even when there is no
>traffic. Brilliant.
>
>Modern hardware doesn't interrupt every packet;
>in fact with intel em controllers its easily
>tunable, so you get the advantages of polling
>without the disadvantages of having a system
>designed by an idiot. Polling will cause you to
>lose tons of packets under bursts of heavy load.
>Although it is downright comical that you're
>concerned about cpu cycles but you were using the
>slowest, least efficient ethernet controller ever
>conceived.
>
>The fxp driver has a built-in hold off of 6000
>ints/sec (which is 1/6000th of a second for you
>mathletes). There is no reason to use polling
>with intel hardware; in fact its a big negative.
>
>Danial
>
    Heh. We just discussed polling vs interrupts in an embedded systems 
class this past quarter. Interrupts are better for more intermittent use 
and polling is better for more frequent use, as polling is actually a 
deadloop of course-for checking a flag most of the time-with potentially 
a lot of wasted clock cycles before a context switch is made and the 
task that was being polled for is run. Also, considering that actual 
computer hardware isn't going to be running 100% of the time (except for 
the CPU running idle tasks and stuff), interrupts are by far the better 
way to go in general. But yeah... too many interrupts are bad as well...
    Anyhow, that was sidetracking a bit :).
-Garrett