On 10/24/2013 04:58 PM, Tim Chen wrote:
Do we want to inline the unlock? Will that prevent proper profile accounting of unlock overhead? Can we keep the mcs_spin_unlock and mcs_spin_lock in the same kernel/mcs_spinlock.c file? That makes it easier to read and maintain the code.
The unlock code is fast. The lock code, however, can run for a long time. It will greatly increase the reported time spent in the calling function if it is inlined. The same is true for spinlock. The _raw_spin_lock() is a real function while _raw_spin_unlock() is inlined in most cases.
Yes, I can bring the lock function back to the mcs_spinlock.h file with name like _raw_mcs_spin_lock() and the mcs_spin_lock() in mcs_spinlock.c will include the raw function. In that way, the mcs_spin_lock() will still be a separate function while both the lock and unlock code will be together.
Can you check if you have applied all the previous MCS patches? The last two for barrier corrections and optimizations seem to be missing. MCS Lock: optimizations and extra comments https://lkml.org/lkml/2013/10/2/644 MCS Lock: Barrier corrections https://lkml.org/lkml/2013/10/2/650 Thanks. Tim
Apparently, I does have all the MCS patch in my git tree. I will regenerate a new one with the right diff. Thank for the review.
-Longman -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
