Re: DEVICE_POLLING with SMP

From: Kevin Day (toasty_at_dragondata.com)
Date: 01/29/04

  • Next message: Lars Eggert: "European USB DSL modems?" 
    Date: Thu, 29 Jan 2004 01:36:50 -0600
To: Vlad Galu <dudu@diaspar.rdsnet.ro>

    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

    _______________________________________________
    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: Lars Eggert: "European USB DSL modems?"

    Relevant Pages

    • Re: f0dders Fabulous Wait States.
      ... And then you have a 1-second latency before you detect process ... > demand in one place only, the Sleep API and it places no other overhead ... The OS doesn't use polling for this kind of thing, ...
      (alt.lang.asm)
    • Re: hyper threading.
      ... I know how device polling works. ... No buffering was necessary. ... just decided to stop using interrupts to eliminate that problem. ... > overhead, even with no traffic. ...
      (freebsd-questions)
    • Re: hyper threading.
      ... I know how device polling works. ... No buffering was necessary. ... just decided to stop using interrupts to eliminate that problem. ... > overhead, even with no traffic. ...
      (freebsd-questions)
    • Re: Giant-free polling [PATCH]
      ... P> +> too much overhead to the code. ... The original idea of handling arrays ... IFCAP_POLLING, which indicate whether interface support polling and whether ...
      (freebsd-net)
    • RE: DEVICE_POLLING with SMP
      ... >> threads to handle polling may bring too much overhead. ... > matter all that much, the CPU is idle, and I can't imagine it ... > got a system acting as a router with 8 network interfaces on it. ...
      (freebsd-net)