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

From: Luigi Rizzo (rizzo_at_icir.org)
Date: 10/07/05

  • Next message: Gleb Smirnoff: "Re: [REVIEW/TEST] polling(4) changes"
    Date: Fri, 7 Oct 2005 02:35:39 -0700
    To: dima <_pppp@mail.ru>
    
    

    On Fri, Oct 07, 2005 at 01:28:58PM +0400, dima wrote:
    > > 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().

    and spend their time fighting for the locks.
    The "ideas discussed in march" tried to point out exactly that problem.

    cheers
    luigi

    > _______________________________________________
    > 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"
    _______________________________________________
    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: Gleb Smirnoff: "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)