Re: device polling takes more CPU hits??

From: Marko Zec (zec_at_tel.fer.hr)
Date: 07/27/04

  • Next message: Luigi Rizzo: "Re: device polling takes more CPU hits??" 
    To: Luigi Rizzo <rizzo@icir.org>
Date: Tue, 27 Jul 2004 21:56:07 +0200

    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@800 MHz P-III@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
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Luigi Rizzo: "Re: device polling takes more CPU hits??"

    Relevant Pages

    • Re: device polling takes more CPU hits??
      ... > I'm just trying to dig into how the current polling implementation is supposed ... > Here are some very rough measurements on how long can a single microuptime() ... > tick, this would equal to 9 us per tick. ...
      (freebsd-net)
    • Re: Issues with a Large Fat pipe Network simulation
      ... > Luigi Rizzo wrote: ... >> which means the packet is intercepted both in the input and ... > I went to see if there were any sysctl's I could tune a bit. ... > polling (which means we can't do SMP on the dummynet system, ...
      (freebsd-net)
    • Re: time delay
      ... Another serious problem here is that in general, you cannot reliably compare ... One should compare difference between starting tick count and current tick ... > the problem to see if polling can be avoided. ... > asynchronous notification, see my essay on asynchronous process ...
      (microsoft.public.vc.mfc)
    • Re: [REVIEW/TEST] polling(4) changes
      ... >> It adds a stub function call every tick. ... >> immediately if no interfaces do polling. ...
      (freebsd-net)
    • Re: [REVIEW/TEST] polling(4) changes
      ... >> It adds a stub function call every tick. ... >> immediately if no interfaces do polling. ...
      (freebsd-arch)