device polling takes more CPU hits??

[Marko Zec]

On Tuesday 27 July 2004 16:39, Luigi Rizzo wrote:
> > what timecounter method are you using, i8254 or TSC? The polling code
> > frequently calls microuptime(), which is very expensive (slow) with
> > i8254,
>
> it is not _that_ frequently, it should be twice per tick. Even with
> the 8254 i don't think this amounts to more than 4-5us, which
> is a couple of percent.


Luigi,

I'm just trying to dig into how the current polling implementation is supposed 
to work, so pls. correct me if I'm wrong.

Doesn't the polling code do three calls to microuptime() per each tick - the 
first one in hardclock_device_poll(), then again in netisr_poll(), and 
finally in netisr_pollmore()? Actually, there might be several iterations of 
netisr_poll() and netisr_pollmore() in a single clock tick, depending on 
traffic load and how high was kern.polling.each_burst set. Nevertheless, the 
code ensures microuptime() is called only in the first call to _poll, and 
only on the last _pollmore() call, which is cool.

Here are some very rough measurements on how long can a single microuptime() 
call last in average:

        P-III at 800 MHz   P-III at 1200 MHz
i8254   2400 T (3 us)   3600 T (3 us)
TSC     120 T (0.15 us) 120 T (0.1 us)

So, if there are three polling-related calls to microuptime() on each clock 
tick, this would equal to 9 us per tick. Given the observed systems runs with 
HZ=4000, this translates to about 35 ms of overhead each second, or only 3.5% 
of "wasted" CPU cycles. So basically you're right, the problem should be 
somewhere else...

Marko