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

    • Re: API change for bus_dma
      ... Justin T. Gibbs wrote: ... > 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. ... what we want to achieve is as few lock acquires and releases ...
      (freebsd-arch)
    • RE: [patch] scsi: use lock per host instead of per device for shared queue tag host
      ... Subject: scsi: use lock per host instead of per ... device for shared queue tag host ...
      (Linux-Kernel)
    • Re: [patch] scsi: use lock per host instead of per device for shared queue tag host
      ... Promise_Linux; Jens Axboe ... Subject: scsi: use lock per host instead of per ... device for shared queue tag host ... Yes, this piece of code of allocating tag, in itself, is safe. ...
      (Linux-Kernel)
    • Re: [patch] scsi: use lock per host instead of per device for shared queue tag host
      ... Subject: scsi: use lock per host instead of per ... device for shared queue tag host ... Yes, this piece of code of allocating tag, in itself, is safe. ...
      (Linux-Kernel)
    • 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)