On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra peterz@infradead.org 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 BAt 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