RE: DEVICE_POLLING with SMP

From: Don Bowman (don_at_sandvine.com)
Date: 01/29/04

  • Next message: Bruce M Simpson: "Re: European USB DSL modems?"
    To: 'Kevin Day' <toasty@dragondata.com>, Vlad Galu <dudu@diaspar.rdsnet.ro>
    Date: Thu, 29 Jan 2004 13:10:30 -0500
    
    

    > From: Kevin Day [mailto:toasty@dragondata.com]
    > On Jan 29, 2004, at 1:04 AM, Vlad Galu wrote:
    > >
    > > I see no reason for it. Having to switch between multiple kernel
    > > threads to handle polling may bring too much overhead.
    > >
    > >
    >
    > Would that really be happening though?
    >
    > If polling is happening in the idle loop, extra overhead
    > doesn't really
    > matter all that much, the CPU is idle, and I can't imagine it
    > being any
    > worse during a livelock inducing amount of traffic.
    >
    > If it's polling during any other time, the code is exactly the same
    > between the UP and SMP case, and I can't imagine the overhead
    > being all
    > THAT much worse, would it?
    >
    > My primary goal with it is to stop thrashing context switches
    > when I've
    > got a system acting as a router with 8 network interfaces on it. Even
    > with network card interrupt coalescing there is a whole lot of
    > interrupt activity going on, which polling seems to make a noticeable
    > difference with polling enabled. I'm also very interested in
    > polling's
    > ability to more gracefully handle extremely heavy network traffic
    > without getting into livelock, which may be worth it to some people
    > prone to DoS activity when they have a whole lot of bandwidth to deal
    > with.
    >
    > I'd be willing to chip in a few bucks for development time if anyone
    > wants to make the changes to try it out. It didn't look that
    > difficult,
    > but my time is pretty booked right now.
    >
    > -- Kevin

    On 4.X, you can simply comment out the check for device polling
    and MP operation. The system will now work fine. It will not,
    however, poll on idle.

    We are running this way and it works very well.

    Polling on idle for MP requires a bit more work. If you do that
    work, you will have some locking issues to solve.

    I have not tried this on current yet.

    --don
    _______________________________________________
    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: Bruce M Simpson: "Re: European USB DSL modems?"

    Relevant Pages

    • Re: [antinvidia@gmail.com: some questions about bge(4)]
      ... known bugs cause brgphy_serviceto often lose a packet. ... if the system can't actually poll at 1/HZ. ... since at least 1500 packets of buffering would be needed for polling ... Polling in idle can work better if the system is actually idle. ...
      (freebsd-net)
    • [REVIEW/TEST] polling(4) changes
      ... When Giant was removed from polling a problem was introduced. ... The idle poll thread can enter polling handler on ...
      (freebsd-arch)
    • [REVIEW/TEST] polling(4) changes
      ... When Giant was removed from polling a problem was introduced. ... The idle poll thread can enter polling handler on ...
      (freebsd-net)
    • Re: DEVICE_POLLING with SMP
      ... If polling is happening in the idle loop, extra overhead doesn't really ... got a system acting as a router with 8 network interfaces on it. ...
      (freebsd-net)
    • Re: Polling tuning and performance
      ... network traffic and that only by polling). ... I am unhappy to report that my fine-tuned interrupt handling ... sucking in packets as fast as possible with minimal loss. ... of power) unless the system can rarely be idle anyway, ...
      (freebsd-performance)