On Fri, Sep 09, 2016 at 11:51:48AM +0200, Peter Zijlstra wrote: > 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. Completions can be used as hacks for some of it - we have two or three places where we do that in XFS. Using semaphores doesn't seem very popular. Also I'd much prefer to have a proper lock instead of working around it, most importantly to get good lockdep support. And none of that addresses the fact that we're talking about a shared/exclusive lock here. > > 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. Yes - pointless is still the best case. > 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.. That's often true, but not always. There is things like battery backed DRAM which is very deterministic, and there is a lot of work going on to provide relatively deterministic ways of using flash storage. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
