Re[2]: [REVIEW/TEST] polling(4) changes

From: dima (_pppp_at_mail.ru)
Date: 10/07/05

  • Next message: Luigi Rizzo: "Re: [REVIEW/TEST] polling(4) changes" 
    To: Gleb Smirnoff <glebius@FreeBSD.org>
Date: Fri, 07 Oct 2005 13:28:58 +0400

    > d> Seems to be a first considerable step regarding the ideas discussed in March :)
    > d> But, my idea about the separate locking of each interface dissappeared from this implementation. mtx_poll is good to protect the pollrec array and other sensitive variables. But we could get advantage of SMP machines writing polling loops like this:
    > d>
    > d> for( i = 0; i < poll_handlers; ++i ) {
    > d> mtx_lock( &iface_lock[i] );
    > d> pr[i].handler(pr[i].ifp, POLL_ONLY, count);
    > d> mtx_unlock( &iface_lock[i] );
    > d> }
    >
    > What is the benefit here? The driver must have its own lock.

    Well, consider the absense of the mtx_poll lock:

    - mtx_lock( &mtx_poll );
      for( i = 0; i < poll_handlers; ++i ) {
    + mtx_lock( &iface_lock[i] );
        pr[i].handler( pr[i].ifp, POLL_ONLY, count );
    + mtx_unlock( &iface_lock[i] );
      }
    - mtx_unlock( &mtx_poll );

    So, several kernel threads in an SMP machine can poll different interfaces simultaneously. And mtx_lock should only be used in ether_poll_[de]register().

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Luigi Rizzo: "Re: [REVIEW/TEST] polling(4) changes"

    Relevant Pages

    • Re: freebsd-current Digest, Vol 79, Issue 14
      ... Unsubscribe me. ... > number of lock operations for the common cases which resulted in a couple ... So, since there is no driver, the device gets powered down as soon as the ... >> shows up as normal PCI device, but exports the console to the network even ...
      (freebsd-current)
    • Re: OS Question
      ... driver, should not distress you. ... I've made the unwarranted assumption that having multiple threads is ... To protect data in user mode ... Permanence (if apps all crash the lock state is retained because ...
      (microsoft.public.development.device.drivers)
    • Re: LOR with netisr changes
      ... ::> It's just a bug in the driver. ... the softc and is intended to be covered by the driver's softc lock. ... this is a hack to work around a recursion in net80211. ...
      (freebsd-current)
    • Re: 6.0-BETA2: taskqueue_drain for if_xl.c:2796
      ... let's go back to the detach case where you actually need a drain. ... guarantee that that won't be forever since it can ensure the task handler ... with the lock held the entire time and doesn't drop it. ... Also, in general the entry points to the driver (ifnet functions, ifmedia ...
      (freebsd-current)
    • Re: [PATCH] Remove process freezer from suspend to RAM pathway
      ... My question referred to drivers trying to bind or unbind a device ... The thread trying to bind is holding a lock which is ... Spinning in the driver with the lock not held is impossible, ... would be easiest to jump directly into the freezer! ...
      (Linux-Kernel)