{"push_id":783004650,"size":1,"distinct_size":1,"ref":"refs/heads/pac-5.1","head":"55b62d5aa4b21255f32b0ecfc862bcfee8f69e5a","before":"95008e4cb3c6325d3cdcac6d657e205890b7ca4e","commits":[{"sha":"55b62d5aa4b21255f32b0ecfc862bcfee8f69e5a","author":{"email":"265264fed90bdf8e813a354375ec16f47ebdb1c5@linutronix.de","name":"Sebastian Andrzej Siewior"},"message":"locking/rtmutex: Drop usage of __HAVE_ARCH_CMPXCHG\n\nThe rtmutex code is the only user of __HAVE_ARCH_CMPXCHG and we have a few\nother user of cmpxchg() which do not care about __HAVE_ARCH_CMPXCHG. This\ndefine was first introduced in 23f78d4a0 (\"[PATCH] pi-futex: rt mutex core\")\nwhich is v2.6.18. The generic cmpxchg was introduced later in 068fbad288\n(\"Add cmpxchg_local to asm-generic for per cpu atomic operations\") which is\nv2.6.25.\nBack then something was required to get rtmutex working with the fast\npath on architectures without cmpxchg and this seems to be the result.\n\nIt popped up recently on rt-users because ARM (v6+) does not define\n__HAVE_ARCH_CMPXCHG (even that it implements it) which results in slower\nlocking performance in the fast path.\nTo put some numbers on it: preempt -RT, am335x, 10 loops of\n100000 invocations of rt_spin_lock() + rt_spin_unlock() (time \"total\" is\nthe average of the 10 loops for the 100000 invocations, \"loop\" is\n\"total / 100000 * 1000\"):\n\n     cmpxchg |    slowpath used  ||    cmpxchg used\n             |   total   | loop  ||   total    | loop\n     --------|-----------|-------||------------|-------\n     ARMv6   | 9129.4 us | 91 ns ||  3311.9 us |  33 ns\n     generic | 9360.2 us | 94 ns || 10834.6 us | 108 ns\n     ----------------------------||--------------------\n\nForcing it to generic cmpxchg() made things worse for the slowpath and\neven worse in cmpxchg() path. It boils down to 14ns more per lock+unlock\nin a cache hot loop so it might not be that much in real world.\nThe last test was a substitute for pre ARMv6 machine but then I was able\nto perform the comparison on imx28 which is ARMv5 and therefore is\nalways is using the generic cmpxchg implementation. And the numbers:\n\n              |   total     | loop\n     -------- |-----------  |--------\n     slowpath | 263937.2 us | 2639 ns\n     cmpxchg  |  16934.2 us |  169 ns\n     --------------------------------\n\nThe numbers are larger since the machine is slower in general. However,\nletting rtmutex use cmpxchg() instead the slowpath seem to improve things.\n\nSince from the ARM (tested on am335x + imx28) point of view always\nusing cmpxchg() in rt_mutex_lock() + rt_mutex_unlock() makes sense I\nwould drop the define.\n\nChange-Id: Ib3d7623f273c03fe2fe87ba9ddb7fcc272330c51\nSigned-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>\nCc: Arnd Bergmann <arnd@arndb.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: will.deacon@arm.com\nCc: linux-arm-kernel@lists.infradead.org\nLink: http://lkml.kernel.org/r/20150225175613.GE6823@linutronix.de\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>","distinct":true,"url":"https://api.github.com/repos/Split-Screen/android_kernel_oneplus_msm8974/commits/55b62d5aa4b21255f32b0ecfc862bcfee8f69e5a"}]}