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 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 -- Joachim Worringen, Software Architect, Dolphin Interconnect Solutions phone ++49/(0)228/324 08 17 - http://www.dolphinics.com _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
