Hey, Thanks for reviewing. Op 02-04-13 13:00, Peter Zijlstra schreef: > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote: >> +Reservation type mutexes >> +struct ticket_mutex { >> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock, > That's two different names and two different forms of one (for a total > of 3 variants) for the same scheme. > > FAIL... It's been hard since I haven't seen anything similar in the kernel, I originally went with tickets since that's what ttm originally called it, and tried to kill as many references as I could when I noticed ticket mutexes already being taken. I'll fix up the ticket_mutex -> reservation_mutex, and mutex_reserve_* -> reserve_mutex_* > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote: >> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow: >> + Similar to mutex_reserve_lock, except it won't backoff with >> -EAGAIN. >> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you >> + unreserved all reservation_locks so no deadlock can occur. >> + > I don't particularly like these function names, with lock > implementations the _slow post-fix is typically used for slow path > implementations, not API type interfaces. I didn't intend for drivers to use the new calls directly, but rather through a wrapper, for example by ttm_eu_reserve_buffers in drivers/gpu/drm/ttm/ttm_execbuf_util.c > Also, is there anything in CS literature that comes close to this? I'd > think the DBMS people would have something similar with their > transactional systems. What do they call it? I didn't study cs, but judging from your phrasing I guess you mean you want me to call it transaction_mutexes instead? > Head hurts, needs more time to ponder. It would be good if someone else > (this would probably be you maarten) would also consider this and > explore > this 'interesting' problem space :-) My head too, evil priority stuff! Hacky but pragmatical workaround for now: use a real mutex around all the reserve_mutex_lock* calls instead of a virtual lock. It can be unlocked as soon as all locks have been taken, before any actual work is done. It only slightly kills the point of having a reservation in the first place, but at least it won't break completely -rt completely for now. ~Maarten _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel