On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: >> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the >> wait >> times of older task. > > No, imagine the following: > > struct ww_mutex A, B; > struct mutex C; > > task-O task-Y task-X > A > B > C > C > B > > At this point O finds that Y owns B and thus we want to make Y 'yield' > B to make allow B progress. Since Y is blocked, we'll send a wakeup. > However Y is blocked on a different locking primitive; one that doesn't > collaborate in the -EDEADLK scheme therefore we don't want the wakeup to > succeed. Yeah, I've thought about this some more and the special sleep state seems to be only required to ensure we don't cause spurious wakeups for other any other reasons a task blocks. But I think we can use that kick-current-holder approach to ensure that older tasks get the lock in a more timely fashion than the current code. I've tried to detail it a bit with another 3 task example - that seems to be the point where the fun starts ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
