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