Re: API change for bus_dma

From: Justin T. Gibbs (gibbs_at_scsiguy.com)
Date: 06/28/03

  • Next message: Ian Dowse: "Unmounting by filesystem ID" 
    Date: Sat, 28 Jun 2003 15:33:25 -0600
To: Scott Long <scottl@freebsd.org>, John Baldwin <jhb@freebsd.org>

    > 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
_______________________________________________
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: Ian Dowse: "Unmounting by filesystem ID"

    Relevant Pages