Re: Giant-free polling [PATCH]

From: Gleb Smirnoff (glebius_at_FreeBSD.org)
Date: 03/11/05

  • Next message: dima: "Re[2]: Giant-free polling [PATCH]" 
    Date: Fri, 11 Mar 2005 17:28:05 +0300
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>

    On Fri, Mar 11, 2005 at 03:14:50PM +0100, Pawel Jakub Dawidek wrote:
    P> On Fri, Mar 11, 2005 at 04:55:25PM +0300, dima wrote:
    P> +> I thought about using list also, but considered it to bring
    P> +> too much overhead to the code. The original idea of handling arrays
    P> +> seems to be very elegant.
    P>
    P> Overhead? Did you run any benchmarks to prove it?
    P> I find list-version much more elegant that using an array.

    It is also a small cookie for future. Now we have IFF_POLLING flag and
    IFCAP_POLLING, which indicate whether interface support polling and whether
    it actually does polling. This is not nice, from my viewpoint. I'd like
    to see only IFCAP_POLLING present and turning polling on/off for particular
    interface should be done by inserting/removing iface from polling list.

    This will also remove an extra unlocked check of interface flags (?).

    P> I also don't like the idea of calling handler method with two locks
    P> held (one sx and one mutex)...

    I agree with Pawel. We have LOR here between sx lock and driver lock:

            normal polling: (get sx shared) -> (get driver mutex)
            driver stop: (get driver mutex) -> (get sx exclusive)

    We will have deadlock if this two things process in parallel.

    And the per-interface mutex protects only reentrancy of interface poll
    method, is that right?

    P> There is still an unresolved problem (in your and our patch as well) of
    P> using ifnet structure fields without synchronization, as we don't have
    P> access tointerface's internal mutex, which protects those fields.

    This is unresolved in our patch, too, and I believe throughout many
    other places in kernel. 

    -- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
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: dima: "Re[2]: Giant-free polling [PATCH]"

    Relevant Pages

    • Re: CPU recommendations?
      ... each time you add a new type of motor, ... There is therefore very little benefit in keeping a clean abstract interface and separation of code layers - it adds overhead to the generated code, and it adds overhead to the development. ... generated or used for templates, ...
      (comp.arch.embedded)
    • Re: Laptop shock detection and harddisk protection
      ... new interface every time is painful. ... With syscall polling you have the kernal polling ... better to do some of it in kernel (tp_smapi seems to be doing ... the kernel can trigger the "unload now" event directly. ...
      (Linux-Kernel)
    • 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: Laptop shock detection and harddisk protection
      ... daemon to glue all the interfaces but it would be much better to ... new interface every time is painful. ... With syscall polling you have the kernal polling ... better to do some of it in kernel (tp_smapi seems to be doing ...
      (Linux-Kernel)
    • 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)