Re: API change for bus_dma

From: Scott Long (scottl_at_freebsd.org)
Date: 06/29/03

  • Next message: Justin T. Gibbs: "Re: API change for bus_dma" 
    Date: Sat, 28 Jun 2003 20:03:20 -0600
To: "Justin T. Gibbs" <gibbs@scsiguy.com>

    Justin T. Gibbs wrote:
    >>Ok, after many semi-private discussions, how about this:
    >
    >
    > There is only one problem with this strategy. The original idea
    > of using a mutex allowed the busdma API to use that same mutex as
    > the strategy for locking the fields of the tag, dmamap, etc. In
    > other-words, the agreement would have been that the caller always
    > has the lock held before calling into bus dma, so that bus dma
    > only has to grab additional locks to protect data shared with
    > other clients. For this to work in the more general scheme, you
    > would have to register "acquire lock"/"release lock" functions in
    > the tag since locking within the callback does not allow for the
    > protection of the tag or dmamap fields in the deferred case (they
    > would only be protected *during* the callback).
    >
    > Again, what we want to achieve is as few lock acquires and releases
    > in the common case as possible. For architectures like x86, the only
    > data structure that needs to be locked for the common case of no deferral
    > and no bounce page allocations is the tag (it will soon hold the S/G list
    > passed to the callback). Other implementations may need to acquire other
    > locks, but using the client's lock still removes one lock acquire and
    > release in each invocation that is not deferred.
    >
    > --
    > Justin
    >
    >

    This is becoming wonderfully complex. What is the purpose of storing
    the S/G list in the tag? Are we going to enforce a 1:1 relationship
    between tags and maps? That would really suck for the aac(4) driver.

    Scott

    _______________________________________________
    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: Justin T. Gibbs: "Re: API change for bus_dma"

    Relevant Pages

    • Re: API change for bus_dma
      ... of using a mutex allowed the busdma API to use that same mutex as ... the strategy for locking the fields of the tag, dmamap, etc. ... has the lock held before calling into bus dma, ... would only be protected *during* the callback). ...
      (freebsd-arch)
    • Re: Recursive mutex that can be waited upon (pthread)
      ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
      (comp.programming.threads)
    • [patch 6/8] mutex subsystem, core
      ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
      (Linux-Kernel)
    • [patch 6/8] mutex subsystem, core
      ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
      (Linux-Kernel)
    • [PATCH 4/8] adaptive real-time lock support
      ... The Real Time patches to the Linux kernel converts the architecture ... compromising the integrity of critical sections protected by the lock. ... while retaining both the priority inheritance protocol as well as the ... the RT Mutex has been ...
      (Linux-Kernel)