On Fri, Sep 09, 2016 at 10:44:50AM +0200, Peter Zijlstra wrote: > Do tell; note however that due to the strict write owner, we can do > things like the optimistic spinning which improved writer->writer > performance significantly. > > Also note that !owner locks create problems for RT. Your clearly missed out on our little Linux-RT conference in June :) While I basically agree with you there is an important class of problems that warrant a non-owner release, and that is I/O. The easiest example (which also happens to be somewhat relevant for this thread) is the XFS iolock (or i_rwsem for that matter). We need to hold this over file writes, but for direct I/O those always go out to disk. In the AIO case there simply is no owner left once control is handed off to the disk / controller and we'll only be able to unlock once we get a completion. Currenrly we work around that using i_dio_count and a hashed waitqueue, but in many ways that solution is worse than the problem (and I say that as the person that introduced it!). We have many many similar issues all over the tree, and people are "fixing" it using home grown lock primitives like the one above or using bitlocks (see the recent thread on cross-release semantics for those). I think everyone would be better server by accepting that this case exists and finding a place for it in the framework. E.g. for RT trying to boost something that is fully under control of hardware is pointless, but if we have a way to transfer a lock from an owner to a hardware owned state we could at least boost until that handoff happened. None of that is really relevant for this thread though - no cross release involved in the case that's tripping up lockdep here, just lock "borrowing" using a synchronous work item. The real root cause here is the too small kernel stack that led to this workqueue. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
