Joachim Worringen wrote:
> Garrett D'Amore wrote:
>
>> I think you're right, and it relates to page faulting. The problem I
>> can see is a recursive lock entry in a storage driver. (It would
>> probably be harmless to hold an ordinary adaptive lock in a subsystem
>> that wasn't involved in handling page faults.)
>>
>
> Thanks, Garrett. Still, an authorative answer on this is highly appreciated!
>
> I tested it myself holding a kmutex_t, verifying with dtrace that page
> faults are handled, and it worked for some thousand times, but this
> doesn't mean much after all.
>
>
>> That said, there is a performance implication as well. The copy
>> routines can take a while. Normally, its a bad idea to hold a lock for
>> a long time, as it usually does bad things to your concurrency.
>>
>> For most normal uses of ddi_copyin/copyout, you shouldn't need a lock
>> any way. The normal practice is that the copying handles either before
>> (for copyin) or after (for copyout) the main processing chunk for an
>> ioctl, and you only need the locks in the main processing chunk. (You
>> can do any required data model conversions outside of the lock as well.)
>>
>
> In this case, it is one of my own locks (as indicated) on my own message
> queue, and ddi_copyin() effectively moves data to remote memory (which
> is where the kernel memory is mapped to) using our interconnect
> hardware. It's a low-latency socket replacement.
>
> Thus, holding a lock during this operation is necessary and valid from
> the perspective of my driver.
>
> My final concern is if I need to use a semaphore for locking (as we need
> to do on Linux, to allow for sleeping), which costs some additional us
> vs a kmutex_t.
>
I don't think the semaphore buys you anything. Additionally, it suffers
from being subject to priority inversions, so I generally try to steer
clear of semaphores unless I really do have a situation where the
problem is expressed as a resource counting problem. (And even then,
direct access to the resources with a lock and cv seems to work better
for me at least.)
You can certainly sleep while holding an ordinary priority mutex. It
just might do bad things for performance, and you have to worry about
possible recursive scenarios.
-- Garrett
>
>> I wouldn't put too much faith in what uiomove claims (or in this case
>> fails to claim) -- I suspect it has the same general limitation. It
>> wouldn't be the first time that an important consideration was not
>> properly documented in the man pages.
>>
>
> Yes, I made this experience already, i.e. with devmap_umem_setup(9F). I
> also suggested an improvement, but I feel that the process to
> incorporate such is far to complicated (on the same level with changing
> the code of the function?).
>
> Joachim
>
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
