Hi !
These patches are migrate_disable/enable cleanups only
basically migrate_disabe/enable is in all of the locking primitives because
it is not known (or not differenciatable) if the lock is protecting a per
cpu object or not - so all lock primitives that potentially could also be
used for concurrency management of per cpu objects must include
migrate_disable/enable to make them safely preemptible (it could get pushed
of the cpu and the reference would then be invalid).
The location of the migration though is prety much irrelevant as long as the
access is ensured to be while holding the lock and migration being disabled.
Locking/migrate_disable patters thus can be any of:
lock/disable access enable/unlock
disable/lock access unlock/enable
disable/lock access enable/unlock
lock/disable access unlock/enable
Based on this the migrate_disable is pushed down to the latest point before
signaling a successfully acquired lock
Further more the first migrate_disable of the task will try to push the task
of the CPU before actually disabling migration. For cases of unsuccessful
lock acquisition this would lead to unnecessary migration of task like in
int __locked; \
migrate_disable(); \
__locked = spin_do_trylock(lock); \
if (!__locked) \
migrate_enable(); \
__locked; \
This patch set pushes the migrate_disable down to the end of the success
path in the different trylock primitives.
patchs are on top of 3.12-rt4
No change of functional behavior
Signed-off-by: Nicholas Mc Guire <der.herr@xxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
