Hello, On Sat, Oct 29, 2016 at 05:21:26AM +0200, Peter Zijlstra wrote: > On Fri, Oct 28, 2016 at 03:12:32PM -0400, Tejun Heo wrote: > > Hello, Peter. > > > > On Fri, Oct 28, 2016 at 09:07:02PM +0200, Peter Zijlstra wrote: > > > One alternative is to inherit the iowait state of the task we block on. > > > That'll not get rid of the branches much, but it will remove the new > > > mutex APIs. > > > > Yeah, thought about that briefly but we don't necessarily track mutex > > This one I actually fixed and should be in -next. And it would be > sufficient to cover the use case here. Tracking the owners of mutexes and rwsems does help quite a bit. I don't think it's as simple as inheriting io sleep state from the current owner tho. The owner might be running or in a non-IO sleep when others try to grab the mutex. It is an option to ignore those cases but this would have a real possibility to lead to surprising results in some corner cases. If we choose to propagate dynamically, it becomes an a lot more complex problem and I don't think it'd be justfiable. Unless there can be a simple enough and reliable solution, I think it'd be better to stick with explicit marking. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html