On Fri, Sep 09, 2016 at 11:05:44AM +0200, Christoph Hellwig wrote: > Your clearly missed out on our little Linux-RT conference in June :) Indeed. > 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!). Right, the IO problem. > 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). Completions and semaphores don't work? And yes, I need to look at that cross-release muck, but as is that stuff sets my teeth on edge. > 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. Could be worse than pointless, could indicate borkage. But yes, once you have that event you could propagate it up the PI chain and notify things. IO rarely is deterministic, so having RT tasks in a blocked-on chain with it is fail. And yes, there's exceptions etc.. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
